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CMS2  Reverse  Engineering  and 
ENCORE/MODEL  Integration  Study 

Final  Report 


This  is  the  final  report  for  the  contract  N00014-91-C-0240.  It  is  divided  into  two  parts:  one 
addressing  the  CMS-2  Reverse  Engin^ring  Technology,  and  the  other  the  ENCORE/ 
MODEL  Integration  Study. 


Part  I  CMS-2  Reverse  Engineering  Technology 

Part  I  presents  an  overview  of  the  CMS-2  Reverse  Engineering  Technology  (CMS  RET) 
produced  for  this  contract.  It  includes  a  description  of  the  operation  of  the  tool,  as  well  as 
the  work  done,  and  the  portions  reused  from  other  projects.  Chapter  1.0  gives  an  overview 
of  the  work  done.  Chapter  2.0  presents  installation  information  and  recommended  opera¬ 
tion  instructions.  Chapters  3.0  through  7.0  provide  detailed  discussions  of  the  functional 
areas  involved,  and  Chapter  8.0  details  the  formats  of  two  files  which  are  crucial  to  anyone 
customizing  or  extending  CMS  RET. 


Chapter  1.0  Technology  Overview 

The  work  done  for  this  contract  demonstrates  that: 

•Automated  extraction  of  design  information  from  an  existing  software  system  written 
in  CMS-2  can  be  used  to  document  that  system  as-built,  and  that 

•The  extracted  information  can  be  entered  into  the  database  of  a  commercially  avail¬ 
able  CASE  tool  and  manipulated  via  the  CASE  interface. 

The  delivered  prototype  operates  on  Sun/4  workstations  and  interfaces  to  the  Cadre  Team- 
worifc/SD*  and  Cadre  Tcamwork/C  Rev^  CASE  tools.  In  addition,  documentation  is  pro¬ 
vided  in  chapter  8.0  which  will  allow  the  Database  Generator  to  be  reimplemented  in 
order  to  interface  with  other  CASE  tools  which  provide  similar  functionality  to  the  Cadre 
technology. 


1 .  TeamworA/SD  is  a  registered  trademark  of  Cadre  Techntdogies  Inc. 

2.  Teamwork/C  Rev  is  a  trademark  of  Cadre  Technologies  Inc. 
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The  key  features  of  the  CMS  RET  system  arc: 

•The  interactive  visual  interface  to  the  extracted  infcmnation  is  provided  by  a  commer¬ 
cially  available  CASE  tool. 

•  Information  describing  software  system  design  is  automatically  extracted  from  source 

files  and  organized  in  a  language  independent  standard  mode. 

•A  method  has  been  developed  which  exploits  project-specific  commenting  conven¬ 
tions  in  order  to  automatically  extract  comments  to  the  database. 

There  are  three  major  vehicles  of  communication  provided  by  the  TeamworA/SD  interface: 

•  Structure  charts  illustrate  the  calling  relationships  between  modules,  (see  Figure  1) 
•Module  specifications  (Mspecs)  present  a  description  of  each  module,  (see  Figure  2) 
•Data  dictionary  entries  (DDEs)  describe  the  global  variables,  (see  Figure  3) 

In  addition  the  system  will  answer  the  following  questions: 

•Where  is  this  variable  referenced? 

•Which  modules  call  this  one? 


FIGURE  1.  Structure  Chart  generated  by  CMS  RET,  displayed  by  Teamirnrft/SD 
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FIGURE  2.  Mspec  generated  by  CMS  RET,  displayed  by  TeanuroriUSD 


FIGURE  3.  Two  examples  of  DDEs  produced  by  CMS  RET,  displayed  by  Teamwork/SD 


The  objective  of  the  CMS-2  Reverse  Engineering  Technology  is  to  provide  the  information 
for  the  displays  in  Figures  1,  2,  and  3.  To  achieve  this,  GE  built  upon  two  past  projects:  a 
CMS-2  to  Ada  translator  (CMS2Ada)  [1]  and  a  Jovial  Reverse  Engineering  Technology 
(JRET)  [2],  CMS2Ada  provided  CMS-2  language  capabilities  which  could  be  reused,  and 
JRET  provided  a  framework  for  a  general  reverse  engineering  technology  which  could  be 
adapt^  to  fit  CMS-2. 


The  CMS-2  Reverse  Engineering  Technology  is  made  up  of  four  functional  areas: 

1)  Information  Extraction,  2)  Comment  Processing,  3)  Database  Generation,  and  the  4) 
Cadre  Itaxnwork  interface.  The  first  two  functions  (Information  Extraction  and  Comment 
Processing)  operate  on  a  file-by-file  basis,  collecting  relevant  information  into  a  language- 
independent  format.  Database  Generation  builds  a  system-wide  view  of  the  information, 
writing  it  into  a  form  which  Tcdsnwork  can  process.  The  final  functional  area  is  Cadre 
Teamworil/SD.  These  four  functions  work  together  to  visually  present  as-built  architec¬ 
tural  information  about  an  existing  system.  Figure  4  shows  how  these  areas  fit  together. 


N00014-91  -C-0240  Final  Repoit 


May  1992 


3 


I 

t 


The  bulk  of  the  woik  for  this  contract  was  done  on  the  first  two  functional  areas:  Infonna- 
tion  Extraction  and  Comment  Processing.  The  Database  Generator  was  reused  from  JRET 
and  Teamwork/SD  is  a  commercial  product  from  Cadre,  which  was  extended  somewhat 
using  their  extensible  interface.  (These  extensions  were  also  reused  from  JRET.) 
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Chapter  2.0  Automatic  Operation,  Installation,  and  Setup 

2.1  Automatic  Operation 

CMS  RET  is  run  as  a  series  of  steps.  These  steps  are  usually  run  across  all  Computer  Soft¬ 
ware  Configuration  Items^  (CSQs)  in  a  CMS  system  when  the  initial  build  of  the  Teamwork 
database  is  done.  (See  Section  2.3  for  further  details  about  CSQs.)  Over  time,  as  files 
change,  there  may  be  a  need  to  rebuild  the  database.  If  only  a  small  number  of  CSQs  have 
been  affected,  it  may  be  preferable  to  run  rebuild  only  on  the  part  of  the  database  dealing 
with  the  affected  CSQ’s. 

The  $RET_DB_HOME/admin/build-ret  script  will  run  all  the  steps,  either  for  one  CSQ  or 
for  the  whole  CMS  system.  It  takes  care  of  all  the  details  and  housekeeping  involved,  and 
produces  log  files  so  that  the  user  can  monitor  its  progress.  It  is  invoked  as  follows: 

$RET_DB_HOME/admiii/build-ret  [  n  [  CSCI_name]  ] 

R  -  is  an  integer  between  1  and  7  specifying  which  operation  is  to  be  performed.  If  it  is  not 
entered  on  the  command-line,  build-ret  prompts  for  an  input.  The  choices  are  as  follows: 

1  CMS  Rev  pass  3  (information  extraction) 

2  CMS  Rev  Comment  Processing 

3  CMS  Rev  pass  4  (system  integration,  part  1) 

4  Post-Process  CMS  Rev  (system  integration,  part  2) 

5  Create  TeamWork  Database 

6  Dump  TeamWork  Database 

7  Restore  TeamWork  Database 

CSQ.RRRie-  indicates  the  CSQ  on  which  the  specified  operation  should  be  performed.  If 
omitted,  the  processing  will  affect  all  CSQ’s,  as  determined  by  the  contents  of  $RET_DB_- 
HOME/src/search.paths. 

In  normal  operation,  one  would  call  the  script  with  option  1,  then  2,  and  so  on,  until  option 
5  had  been  performed.  A  CSQ  name  is  not  generally  specified  unless  a  particular  CSQ  is 
being  rebuilt  separately  for  some  reason. 

Here  is  the  sequence  of  commands  and  system  responses  which  would  be  issued  to  build  a 
full  CMS  system  which  contains  the  CSQs  COLLECT  and  ANALYZE: 

>  $RET_DB_HOME/adiniii/build'ret  1 

Begin  RET  Build  Program,  The  Apr  21  10:01:36  EDT  1992 
ANALYZE  CMS  Rev  Pass  3  Tue  Apr  21  10:01 :39  EDT  1992 

COLLECT  CMS  Rev  Pass3  The  Apr  21  10:01 :54  EDT  1992 

End  RET  Build  Program,  Tue  Apr  21  10:02:14  EDT  1992 

>  $RET_DB_HOME/adiiiiii/build-ret  2 

Begin  RET  Build  Program,  Tue  Ain:  21  10:02:28  EDT  1992 


1 .  See  DOD-STD-2167A,  June  4, 1985,  for  definitions  rdevant  to  Computer  Software  Organization. 
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ANALYZE  CMS  Rev  Comment  Processing  "Die  Apr  21  10:02:31  EDT  1992 
COLLECT  CMS  Rev  Comment  Processing  Tlie  Apr  21  10:02:42  EDT  1992 
End  RET  Build  Program,  Tue  Apr  21  10:02:50  EDT  1992 

>  $RET_DB_HOME/adiiiiii/build-ret  3 

Begin  RET  Build  Program,  Tde  Apr  21  10:03:03  EDT  1992 
ANALYZE  CMS  Rev  Pass  4a  Tue  Apr  21  10:03:05  EDT  1992 

COLLECT  CMS  Rev  Pass  4a  Tue  Apr  21  10:03:08  EDT  1992 

CMS  Rev  Pass  4b  Tae  Apr  21  10:03:12  EDT  1992 
ANALYZE  CMS  Rev  Pass  4c  Tue  Apr  21  10:03: 15  EDT  1992 
COLLECT  CMS  Rev  Pass  4c  Tue  Apr  21  10:03:23  EDT  1992 
End  RET  Build  Program,  Ttie  Apr  21  10:03:33  EDT  1992 

>  $RET_DB  HOME/admin/build-r^  4 

Begin  RET  BuUd  Program,  Tue  Apr  21  10:03:49  EDT  1992 
ANALYZE  CMS  Rev  Post-Processing  Tue  Apr  21  10:03:51  EDT  1992 
COLLECT  CMS  Rev  Post-Processing  Tue  Apr  21  10:03:55  EDT  1992 
End  RET  Build  Program,  Hie  Apr  21  10:03:59  EDT  1992 

>  $RET_DB_HOME/adtmn/build-ret  5 

Begin  RET  Build  Program,  Tue  Apr  21  10:04:16  EDT  1992 

Starting  crev  and  twk_put  ***  Tue  Apr  21  10:04:18  EDT  1992 
yes  to  proceed,  CTR17C  to  abort:  yes 

crev  and  twk_put  pass  for  ANALYZE  Tue  Apr  21  10:04:21  EDT  1992 
crev  and  twk_put  pass  for  COLLECT  Tue  Apr  21  10:06: 12  EDT  1992 
Completed  crev  and  twk_put  ***  Tue  Apr  21  10:10:46  EDT  1992 
End  RET  Build  Program,  Hie  Apr  21  10:10:47  EDT  1992 

If  the  system  had  been  built  once  already  but  changes  had  occurred  only  in  ANALYZE,  the 
user  could  rebuild  only  that  CSQ  by  issuing  the  same  set  of  commands,  but  with  ANA¬ 
LYZE  appended  to  each. 


Options  6  and  7  are  not  a  normal  part  of  building  the  system.  They  are  useful  for  backups 
and  for  transporting  the  database  between  systems.  They  simply  invoke  the  appropriate 
Cadre  utilities.  When  option  6  is  invoked  without  a  CSCI  name,  the  dump  is  placed  into 
$RET_DB_HOME/dump/twk-dump.  If  a  CSCI  name  is  specified,  then  the  dunqi  goes  into 
$RET_DB_HOME/dump/c5Ci_/iame.twk-dump.  When  option  7  is  chosen,  it  loads  the  files 
from  the  dump  files  written  in  option  6. 


Build-ret  also  produces  log  files.  These  are  found  in  the  directory  $RET_DB_HOME/log. 
Here  is  a  list  of  the  log  files  and  where  they  are  produced: 


passl 

pass3 

pass5 

pass6 

pass7 


csci_/iam€.p3-log 

cscj_/iaw€.p4a-log,  p4b-log,  csci_name.p4c-log 
csciname.twk-log 
twk-dump-log 
csci-nome.twk-dump-Iog 
twk-load-log 
C5Ci-name.twk-load-log 


(if  inviAed  without  CSCI  name) 
(if  invcAed  with  CSCI  name) 

(if  invt^od  without  CSCI  name) 
(if  invcAed  with  CSCI  name) 
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2.2  RET  Installation 


Once  the  distribution  tape  is  received,  the  contents  should  be  extracted  using  tar  (a  Unix 
utility).  This  will  create  a  directory  named  ret,  with  several  subdirecttnies.  All  RET  users 
will  need  to  create  an  environment  variable,  $RET_DB_HOME,  which  contains  the  path 
name  of  this  ret  directory. 


There  are  several  files  in  the  directly  $RET_DB_HOME/sys  which  must  be  customized.  In 
the  files  listed  below,  the  string  “$RET_DB_HOME”  must  be  replaced  with  the  hard-coded 
path  name  of  your  installation’s  ret  dilatory  (e.g.  /conunon/sun4Aet).  The  affected  files 
are: 


dd.menu 

dde.menu 

desktop.menu 

dpi.menu 

file.menu 

ms.menu 

pi.menu 

sc.menu 

config_file 


(1  substitution) 

(1  substitution) 

(1  substitution) 

(1  substitution) 

(1  substitution) 

(1  substitution) 

(2  substitutions) 
(4  substitutions) 
(10  substitutions) 


The  only  other  requirements  are  that  the  Cadre  Ttdsawork  and  Crev  products  must  be 
installed.  Please  refer  to  the  Cadre  documentation  [4]  for  this  procedure. 


2.3  System  Setup 

Once  RET  has  been  installed,  the  user  must  load  into  it  the  source  system  to  be  examined. 
There  are  two  steps  involved  with  this: 

1.  in  $RET_DB_HOM^src,  update  the  file  search.paths  to  contain  only  the  names  of  the 
CSCl’s  which  are  part  of  the  system  to  be  examined. 

2.  in  $RET_DB_HOME/src,  create  a  soft  UNIX  link  to  each  CSCI  entered  in  search.paths. 
(Each  CSCI  should  now  have  a  directory 

3.  filled  with  the  source  files  associated  with  it.) 

It  should  be  noted  that  CMS  RET  views  a  CMS-2  system  as  a  set  of  CSCIs.  Each  CSCI  is  a 
subdirectory  of  the  overall  system  directory,  containing  source  files  which  are  presumably 
related.  Even  if  there  is  only  one  source  directory  for  a  project,  it  should  appear  as  a  subdi¬ 
rectory  of  the  project  itself,  and  be  considered  a  CSO.  It  is  generally  advisaUe  for  the  CSCIs’ 
names  to  be  aU  capital  letters. 
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Chapter  3.0  Information  Extraction 


3.1  User  Perspective 

The  user  will  run  this  pass  on  every  complete  source  file  in  the  CMS-2  system.  (Include 
files  are  brought  in  automatically  by  the  files  which  reference  them.)  This  can  be  done 
using  the  build-ret  script  described  in  Section  2.1,  or  by  issuing  the  command: 

cnis2cdif.p3  •csd  escijname  ( file_names  } 

so  that  each  source  file  in  every  CSCl  is  processed,  file  name  is  a  non-empty  list  of  the 
files  to  be  processed  and  CSC!  name  is  the  name  of  the  CSCI  containing  these  files,  (csci  - 
name  must  not  contain  wild  cards,  but  file_name  may.)  The  commaiul  must  be  issued 
within  the  appropriate  CSCI.  For  each  file  processed,  there  will  result  a  middle  file  and  a 
comment  file,  which  are  used  in  the  later  steps.  The  formats  of  the  middle  and  comment 
files  are  given  in  Chapter  8.0. 

3.2  Internals 

The  Information  Extractor  is  written  in  Ada,  and  has  two  basic  parts  (the  parser  and  the 
extractor),  both  of  which  interface  to  our  internal  representation  of  the  CMS-2  language. 
The  parser  and  internal  representation  were  completely  reused  from  the  CMS2Ada  trans¬ 
lator,  with  a  few  extensions  to  expand  our  language  coverage.  (These  are  detailed  in  the 
description  of  the  parsing  package  in  3.2.2.)  Parts  of  the  extraction  mechanism  were 
adapt^  from  JRET  (the  Jovial  Reverse  Engineering  Technology),  but  much  of  it  was 
rewritten  because  of  the  differences  between  the  internal  representations  of  CMS-2  and 
Jovial.  The  new  version  was  wrinen  with  liberal  use  of  generics  and  non-language  specific 
data  structures,  with  the  hope  that  most  of  it  will  be  reusable  should  we  ever  want  to 
reverse  engineer  anc*ther  language. 

The  remainder  of  this  section  contains  a  brief  description  of  the  packages  in  the  Informa¬ 
tion  Extractor,  the  relationships  between  them,  and  a  more  detailed  look  at  some  of  the 
more  important  packages. 

32.1  The  packages  comprising  the  Information  Extractor 

In  the  list  that  follows,  *  indicates  almost  complete  reuse,  #  indicates  significant  reuse,  and 
italics  indicate  that  the  package  is  generic. 

•Main  *  (contains  main  driver,  handling  command-line  interface  and  file  control) 

•CMS.Records  *  (description  of  the  nodes  which  make  up  the  internal  representation) 

•CMS_Interface  *  (access  routines  fw  CMS_Records) 

•(^S_UtiIs  (some  general  utilities  not  available  in  CMS_Interface) 

•Parse  *  (creates  a  parse  tree,  made  up  of  structures  from  CMS.Records) 

•Lexical  Analysis  * 
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•Symbol  tables  and  symbol  table  management  *  (several  related  packages) 

•Parse  Control  *  (helper  package  for  parser  and  classification  routines) 

•Extract_Info  #  (high-level  node-processing  routines;  basically  sorts  out  the  nodes) 

•  Data.Processing  #  (mid-  and  low-level  routines  specific  to  data  declarations) 

•  Executable_Processing  #  (mid-  and  low-level  routines  specific  to  executable  state¬ 

ments) 

•Option_Processing  (mid-  and  low-level  routines  specific  to  option  statements) 

•Structure_Processing  (mid-  and  low-level  routines  specific  to  structure  statements) 

•Subprogram_Processing  #  (mid-  and  low-level  routines  specific  to  subprogram  decla¬ 
rations) 

•Print  Middle  #  (language-independent  printing  routines;  mainly  utilities) 

•Source Jile  database  *  (associates  nodes  with  file  names  and  line  numbers) 

•Scoping#  (determines  which  data  items  are  global  and  which  are  local) 

•Subprogram  Lists  #  (data  package  for  communication  between  Subprogram_Pro- 
cessing  and  Executable.Processing) 

•  System.Info  (data  package  indicating  what  options  are  currently  in  effect  and  what 

structure  is  being  processed) 

•E)ebug_Flags  *  (framework  for  dubugging) 

•  Comment_Handler  #  (received  comments  and  context  indications  from  the  parser  and 

prints  to  the  comment  file  as  appropriate) 

•Comment_Helper  (Language  specific  utilities  unique  to  comment  handling) 

Figure  5  shows  the  with’ing  relationships  between  these  packages. 
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:  relatively  langnage-indepeiideiit  I _ I  =  language^lependent 

FIGURE  5.  Whh’ing  Relatknsfaips  between  Packages 
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Z2J.  Detailsof  Important  Packages 


Parsing  and  Representation  Packages:  These  include  CMS.Recoids,  CMS.Interface, 
and  the  parser,  lexical  analyzer,  and  symbol-table  packages.  As  a  baseline,  we  reused  these 
packages  from  the  CMSlAda  translator,  but  extended  them  as  part  of  this  contract  to 
address  certain  CMS-2  constructs  which  were  not  previously  handled.  These  include 
macro  expansions  (via  the  means  and  exchange  statements),  user-defined  type  declara¬ 
tions,  and  the  terminate  phrase.  In  addition,  a  means  for  processing  cswitch  dir^tives  was 
designed,  but  not  implemented. 

Parse  JControl:  is  a  generic  package  containing  a  pointer  to  the  top  node  of  the  parse  tree 
and  the  routine  which  calls  the  (instantiated)  parser  and  extractor. 

Extractjnfo:  contains  the  top-level  extraction  routine,  and  those  generalized  routines 
which  classify  each  node  and  drive  the  processing.  The  top-level  extraction  routine  also 
takes  care  of  the  file  control  for  the  middle  file  being  created. 

Visible  Routines: 

Process_A_Node 

Process_Seq_Of_Nodes 

Is_Receptacle 

Process_Receptacle 

Process_Seq_Of_Receptacles 

Is_Expression 

Process.Expression 

Process_Seq_Of_Expressions 

Extract 

DataJProcessing:  contains  routines  to  classify  and  process  the  nodes  which  represent  data 
declarations.  The  processing  includes  checking  the  declaration  for  usages  of  other  data 
items,  and  printing  appropriate  information  to  the  middle  file. 

Visible  Routines: 

Is_Data_Decl 

Process_Data_Decl 

Executable _Processing:  contains  routines  to  classify  and  process  the  nodes  which  repre¬ 
sent  executable  statements.  The  processing  includes  checking  for  data  uses  and  subroutine 
calls,  and  keeping  track  of  any  which  are  found. 

Visible  Routines: 

Is_Executable_Node 

Process_Executable_Node 

Option_Processing:  contains  routines  to  classify  and  process  the  nodes  which  represent 
cation  statements.  The  processing  genmlly  entails  setting  global  variables  n>  reflect  the 
cations  found. 

Visible  Routines: 

Is_Option_Node 
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Proccss_Option_Node 

StructureJProcessing:  contains  routines  to  classify  and  process  the  nodes  which  represent 
structural  statements.  This  processing  generally  consists  of  making  sure  all  statements 
within  the  structure  are  processed. 

Visible  Routines: 

Is_Structure_Node 

Process_Structure_Node 

Subprogntm_Processing:  contains  routines  to  classify  and  process  the  nodes  which  repre¬ 
sent  subprogram  declarations.  This  processing  includes  setting  up  a  framework  in  which 
to  collect  information  about  the  subprogram’s  activities,  making  sure  all  statements  within 
the  subprogram  are  processed,  and  writing  the  information  collected  to  the  current  middle 
file. 

Visible  Routines: 

Is_Subprogram_Decl 

Process_Subprogram_Decl 

Print_Middle:  is  a  generic  package  which  contains  a  file  pointer  to  the  middle  file,  and 
routines  to  handle  much  of  the  printing  fcH*  it  The  idea  behind  this  package  is  that  the  for¬ 
mat  of  the  middle  file  is  language-independent,  even  though  the  internal  representation  of 
the  information  is  not  Therefore,  the  routines  in  print_middle  use  language-specific 
instantiated  “helper”  routines  in  order  to  access  any  extra  information  needed,  and  then 
print  everything  out  in  a  standard  format 

Visible  Routines: 

New_Middle_File 

Get_Middle_File 

Qose_Middle_File 

Comma_Space 

Print_Component_Decl 

Print_Extended_Name 

Print_Formals 

Print_Simple_Decl 

Print_Stan_of_Composite_Decl 

Print_Source_Info 

Print_TW_Attribute 

Subprogram_Lists:  is  a  generic  package  which  contains  the  infrastructure  which  the  sub- 
program^rocessing  routines  use  to  keep  trac  k  of  the  reference  information  collected.  It 
serves  as  the  prime  communication  mechanism  between  the  Subprogram_Processing  and 
Executable_Processing  packages. 

Visible  Routines: 

Add_To_Calls 

Print_Calls 

Add_To_Reads 

Print_Reads 
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Add_To_Writes 

Print_Writes 

Print_Rcads_And_Writes 

Initialize_Subprogram_Lists 

Update_Rcads_And_Writcs 

Push_Locals 

Pop_Locals 

Add_To_Locals 

Add_To_Params 

Mem_Locals 

Mem_Params 


Chapter  4.0  Comment  Processing 

4.1  User  Perspective 

The  user  will  run  this  pass  on  every  .comment  file  produced  as  a  result  of  the  Information 
Extraction.  This  can  be  done  using  the  build-ret  script  described  in  Section  2.1,  or  by  issu¬ 
ing  the  command 

gawk  'f  $RET_DB_HOME/cnKirev/bin/coments.awk  *.comments 

(see  Section  2.2  for  the  proper  setting  of  the  $RET_DB_HOME  environment  variable). 
(^awk  is  gnu  awk.  If  your  installation  does  not  own  a  copy,  use  the  one  in  $RET_DB_- 
HOME/cmsrev/bin.)  Since  this  capability  must  be  sensitive  to  the  commenting  conven¬ 
tions  of  the  current  project,  it  is  recommended  that  the  user  customize  the  comments.awk 
program  to  reflect  the  prevailing  conventions.  Those  plaiming  to  do  this  customization 
would  be  well-advised  to  read  Section  8.2,  which  describes  the  format  of  the  .comment 
files. 

4.2  Internals 

The  .comment  files  written  by  the  Information  Extractor  contain  a  line  for  each  comment 
found,  and  one  for  each  “interesting”  construct  encountered  in  the  source  code.  Interesting 
constructs  include  data  declarations,  subprogram  declarations,  header  blocks,  proc  and  dd 
statements.  Thus  the  files  contain  not  only  the  comments,  but  some  context  condensed  out 
of  the  source  code.  A  distinction  is  made  between  COMMENT ...  $  constructs  and  in-line 
comments,  resulting  in  even  more  context  infoimation. 

The  purpose  of  the  commentsjiwk  program  is  to  create  an  .ext_com  file  for  each  subpro¬ 
gram  declaratimi  found  in  a  xommoit  file.  This  .ext_com  file  contains  exactly  the  text 
that  will  eventually  appear  in  the  Mspec  for  that  subprogram  in  the  Cadre  database.  The 
standard  commentsjiwk  program,  included  with  this  release,  selects  as  relevant  the  com¬ 
ments  which  fall  between  the  subprogram’s  declaration  and  its  actual  code. 


Na)0I4.91-C-0240  HmI  Repon 


Mqr  1992 


13 


Chapter  5.0  System  Integration 

5.1  User  Perspective 

There  are  several  passes  involved  in  this  activity.  They  can  be  run  via  the  build-ret  script 
described  in  Section  2.1,  or  by  issuing  the  following  commands: 

(in  each  CSCI  directory) 

ciiis2cdif.p4a  -csd  eseijname  *.iiuddle 

(in  parent  directory) 

cat  *.decls  |  sort  |  awk  «f  $RET_DB_HOME/adiniii/p4b,awk 
ciiis2cdif.p4b  -P  search.paths  *.export 

(in  each  CSCI  directory) 

cins2cdif.p4c  -csd  csci_name  -crev  -mspec  -dde  *.niiiddle 
$RET_DB_IIOME/adiiiiii/do_post  csci_name 

(See  Section  2.2  for  a  description  of  the  $RET_DB_HOME  environment  variable.)  If  the 
passes  are  run  outside  of  the  build-ret  script,  there  is  a  set  of  files  which  must  exist  before 
running  them.  In  each  CSQ,  liiiiits.txt  must  be  present  This  should  be  copied  fiom 
$RET_DB_HOM^admin,  or  it  can  be  made  an  empty  file,  in  which  case  no  DDE’s  will  be 
produced.  In  the  CSQ’s  parent  directtwy,  search.paths  must  exist  It  will  contain  the 
names  of  the  CSCH’s  which  are  to  be  active  (this  would  typically  be  all  of  the  subdirecto¬ 
ries). 

The  output  of  these  steps  is  the  set  of  files  twk.script,  reLcrev,  retctl,  retdd  and  retins. 
These  are  used  in  building  the  Teamwork/SD  reverse  engineering  database. 

5.2  Internals 

The  purpose  of  these  steps  is  to  reconcile  any  name  clashes  which  may  occur,  either 
within  or  between  CSCI’s,  to  resolve  inter-CSCI  references,  and  to  build  the  CDIF^  repre¬ 
sentation  of  each  CSCI’s  infonnation.  Briefly,  the  processing  responsibilities  are  divided  as 
follows:  cins2cdif.p4a  compiles  two  lists  fm*  each  C^SCI,  one  for  data  item  names  and  one 
for  subprogram  names,  pdboiwk  and  ciiis2cdif.p4b  create  new  names  where  necessary  to 
avoid  name  clashes.  cins2cdif.p4c  creates  the  CDIF  files  which  will  be  fed  into  the  Team¬ 
work  database,  and  a  script  for  loading  them,  do-post  edits  a  few  files  so  that  the  Team¬ 
work  extensions  will  read  them  correctly. 


1.  CASE  Data  Intochange  Format 
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Chapter  6.0  Building  the  Teamwork/SD  Reverse  Engineering 
Database 


6.1  User  Perspective 

The  CSQ’s  for  the  databases  being  constructed  must  exist  in  Ttanmork.  they  do  not, 
then  start  Teamwork  and  create  new  models  with  these  CSCIs’  names.  Once  the  models 
exist,  construct  their  respective  databases  either  by  using  the  build-ret  script  described  in 
Section  2.1,  or  by  issuing  the  following  command  in  each  CSQ: 

/bin/sh  twk.script 

6.2  Internals 

This  step  invokes  crev  and  twk_put  to  build  the  database,  crev  uses  reLcrev  and  ret.ctl  to 
produce  the  Teamwork  structure  charts,  and  twk_put  creates  Mspecs  from  retms,  and 
DDEs  from  ret.dd. 

Chapter  7.0  Team  Work  Environment 

7.1  Invocation 

In  order  to  use  the  extensions  GE>supplied  extensions.  Teamwork  must  be  invoked  using 
the  RET  config_file.  This  config_iile  must  be  customized  during  installation,  as  described 
in  Section  2.2.  Once  that  is  done,  invoke  Teamwork  as  follows: 

teamwork  •€  $RET_DB_HOM  E/sys/config_file 
(See  Section  2.2  for  the  proper  setting  of  the  $RET_DB_HOME  environment  variable.) 

7.2  Basic  TeamH'ori^  Displays 

Most  of  the  Teamwork  displays  are  standard  to  the  Teamwork  environment,  and  are 
explained  in  the  (Hadre  documentation.  The  Mspec  and  DDE  displays  are  somewhat  cus¬ 
tomized  for  RET,  so  they  are  described  here. 

The  Mspec  (Module  Specification)  display  is  intended  to  describe  the  important  aspects  of 
a  module.  In  this  context,  a  module  corresponds  to  a  subprogram.  The  information  con¬ 
tained  is  the  following:  subprogram  parameter  names  and  directions;  global  variables 
accessed,  along  with  an  indication  of  whether  they  are  read  or  written;  modules  called; 
calling  modules;  and  comments  extracted  from  the  source  code  of  the  module. 

The  DDE  (Data  Dictionary  Entry)  display  is  intended  to  convey  the  important  features  of  a 
data  item.  The  information  supplied  for  a  simple  variable  includes:  type  information; 
actual  location  (file  and  line  number)  of  its  declaration;  and  location  of  its  declaration,  tak¬ 
ing  into  account  include  expansions.  For  arrays,  the  number  of  dimensions,  direction,  and 
any  field  names  are  also  included. 
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13  GE-Supplied  Extensions 


The  user  should  consult  the  Cadre  documentation  for  information  on  the  standard  Team- 
work  environment  [3].  What  follows  hov  is  a  description  of  the  GE-supplied  extensions  to 
that  environment,  and  guidelines  for  how  to  use  them. 

Displaying  Source  Files:  There  are  times  when  the  summarized  information  is  not  suffi¬ 
cient  for  the  task  at  hand.  In  these  cases,  it  is  useful  to  have  a  quick  method  of  viewing  the 
actual  source  code.  In  order  to  do  this,  select  a  module  of  interest  from  a  stracture  chart  or 
Mspec,  or  a  data  item  from  a  DDE,  and  choose  the  RET  menu  item  “Display  Module 
Source”.  The  corresponding  source  file  will  be  displayed,  and  the  user  can  then  search  on 
the  name  of  the  module  or  data  item  in  order  to  find  the  desired  declaration. 

Displaying  Data  Usages:  It  is  often  important  to  know  which  modules  use  a  particular 
global  variable.  This  information  is  available  from  the  full  Data  Dictionary  as  well  as  the 
Mspec  display.  To  view  it,  simply  select  the  desired  global  variable,  and  choose  either 
“Display  Where  Ref’  or  “Display  Where  Ref  All”  from  the  RET  menu  (the  latter  extends 
the  search  across  all  active  CSQs).  The  information  will  be  retrieved  and  displayed  in  a 
window  which  lists  the  modules  in  which  that  data  item  is  referenced.  From  that  window, 
the  user  may  move  to  the  Mspec  for  any  of  the  referencing  modules  by  selecting  its  entry 
and  choosing  the  RET  menu  item  “Show  Module  Spec”. 

Displaying  Calling  Modules:  Although  the  structure  charts  are  effective  in  showing  the 
called  modules  of  a  particular  subprogram,  it  can  be  tedious  working  backwards  to  find  the 
calling  modules.  There  are  two  ways  to  find  this  information  easily.  The  first  method  is  to 
view  the  Mspec  of  the  desired  nK)dule  and  find  the  list  of  calling  nxxlules.  The  second 
method  is  to  select  the  desired  trxxiule  from  a  structure  chart  and  choose  the  RET  menu 
item  “Display  (Ming  Modules”.  The  information  will  be  retrieved  and  displayed  in  a 
window  which  lists  the  nxxlules  which  call  the  selected  one.  From  that  window,  the  user 
nuiy  access  the  Mspec  for  any  calling  nxxiule  by  selecting  its  entry  and  choosing  the  RET 
menu  item  “Show  Module  Spec”.  (From  there,  “Show  SC’  from  the  Whole_Mspec  menu 
will  bring  up  the  corresponding  structure  chart) 

Displaying  Mspecs  from  Structure  Charts:  When  viewing  a  structure  chart,  select  the 
desired  module  and  choose  the  RET  menu  item  “Open  Module  Spec”.  The  corresponding 
Mspec  will  appear. 

Displaying  DDE’s  for  the  Fields  of  a  Table:  When  viewing  the  DDE  of  a  table  or  array,  it  is 
not  enough  to  see  just  that  item’s  information;  the  component  items’  entries  are  equally 
important  These  can  be  viewed  easily  by  highlighting  the  desired  name  within  the  table’s 
DDE  and  then  choosing  the  RET  trwnu  item  “Open  DDE”.  A  new  DDE  window  will  open 
with  the  desired  entry. 

For  a  more  in-depth  description  of  the  GE-enhanced  Teamwork  environment  please  see 
the.CMS  RET  User’s  Manual  found  in  Appendix  A. 
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Chapter  8.0  File  Formats 
8.1  Middle  FUes 


The  middle  files  hold  the  information  which  is  extracted  from  the  CMS  source  files,  before 
it  is  integrated  into  a  system  view.  In  the  case  that  this  technology  were  ported  to  a  CASE 
tool  other  than  Cadre,  these  files  would  be  the  starting  place  for  die  re-implementation.The 
following  is  the  grammar  for  the  middle  files. 

file  ::=  “file”  string_literal  [“csci”  identifier]  {declaration  ) 

declaration  :;=  context_decl  I  extarnal_decl  I  subroutine.decl  I  object_decl  I 
group_decl  I  typc_decl 

context_decl  ::=  “context”  identifier  [  id_list  ]  [  source_info  ] 

context_list  ::=  {  context_decl } 

extemal_decl  ::=  “external  “  global_declaration 

global.declaration  subroutine_decl  I  object_decl  I  type_decl 

subroutine.decl  procedure_decl  I  function_decl 

procedure_decl  ::=  “procedure”  identifier  [source_info] 
subroutine.info  “end” 

function.decl  ::=  “function”  identifier  {source_info]  type_info 
subroutine.info  “end” 

subroutine.info  ::=  [  “long”  “name”  string.literal  ] 

[formal.list]  [  local.list  ]  [  context.list  ]  [  calls.list  ]  [  reads.list  ] 

[  writes.list  ]  [  reads.writes.list  ]  [  nested.subs.list  ] 

[  “header^’  “^e”  string.literal  ]  [  “copy”  “files”  string  literal  ] 

[  pseudo.code.list] 

object.decl  ::=  simple.decl  I  composite.decl 

simple.decl ::  =  “simple”  identifier  [  “constant”  ]  [  source.info  ] 

[  “csci”  identifier  ]  tw.attr  type.info  [  “members”  list  ] 

composite.decl  ::=  “composite”  identifier  [  “constant”  ]  composite.class 
[  source.info  ]  [  “csci”  identifier  ]  [  index.info  ]  tw.attr 
( component.list  I  type.info ) 

index.info  ::=  “indexed”  “(“  integcr.literal  “)” 


N00014-91-C-0240  Hml  Rqwn 


Mqr  1992 


17 


tw_attr  ::=  [  tw^prim  ]  tw_flow 

tw_prim  ::=  “PEL”  I  “CEL”  I  “DEL” 

tw_flow  ::=  “controlflow”  I  “dataflow”  I  “bothflow”  I  “store” 

group_decl  ::=  “group”  identifier  [  sourcejnfo  ]  [  “csci”  identifier  ] 

{ declaration  }  “end” 

formaljist  ::=  “fortnals”  “(“  formal  {  formal }  “)” 

formal  identifier  direction  type_info 

local_list  ::=  “locals”  id_list 

a_call  ::=  identifier  [  “nested”  ]  [  actual_list  ] 

actualjist  ::=  “(“  actual  {  actual }  “)” 

actual  ::=  ( “C‘  object_decl  “)” )  I  identifier 

direction  ::=  ( “in”  [  “out”  ] )  I  “out” 

type_decl  ::=  “type”  (simple_type_decl  I  composite_type_decl ) 

simple_type_dccl  “simple”  identifier  [  source_info  ]  [  “csci”  identifier  ] 
tw_attr  type_info  [  “members”  list  ] 

composite_type_decl  ::=  “composite”  identifier  composite_class 
[  sourcejnfo  ]  [  “csci”  identifier  ]  [  index_info  ]  tw_attr 
( componentjist  I  type_info  [  “members”  list  ] ) 

component_list  ::=  “C‘  [  (  sin:q)le_decl  I  composite_decl ) 

{  “,”  ( simple_decl  I  conqwsite.decl ) )  ]  “)” 

composite_class  ::=  string_literal 

type  _info  ::=  string_literal 

calls.Ust  ::=  “calls”  “C‘  a_call  {  “  ”  a_call )  “)” 

reads_list  ::=  “reads”  id_list 

writcs_list  “writes”  id_list 

rcads_writes_list  ::=  “reads_writcs”  id_list 


NOa)14^1-C-(n40  »m1  Rqwft 


Miy  1992 


18 


nestcd_subs_list  “nested”  {  subroutine_decl } 
pseudo_code_list  ::=  “pseudo_code”  list 
Ust  ::=  “(“  string_Uteral  {  “  ”  string_literal }  “)” 
idjist  ::=  “(“  identifier  (  identifier  }  “)” 

source_info  ::=  integer_literal  string_literal  [  integer.literal  string_literal  ] 
identifier  ::=  string_literal  I  rescrved_wonI_of_language 


8.2  Comment  Files 

The  comment  files  contain  both  the  CMS-2  comments  and  some  condensed  context  infor¬ 
mation.  These  are  the  files  which  are  input  to  the  comment  processor,  which  then  produces 
one  .ext_com  file  for  each  subprogram,  containing  any  relevant  comments.  The  awk  script 
of  the  comment  processor  is  user-customizable. 

file  ::=  {entry  } 

entry  ::=  comment_entry  I  context_entry 

comment_entry  ::=  same_line_entry  I  stand_alone_entry 

same_line_entry  ::=  “SAME  LINE:  “  string 

stand_alone_entry  ::=  “03MMENT:  “  string 

context_entry  ::=  data.decl  I  subprogram_decl  I  structural_entry  I 
“CX)DE”  I  “UNKNOWN  CODE” 

data_decl  ::=  “DATA”  I  “EQUALS”  I  “FIELD”  I  “LOADVRBL”  I 
“NTTEMS”  I  “PARAMETER”  I  “SYS-INDEX”  I  ‘TABLE”  I 
“VARIABLE” 

subprogram.decl  ::=  “EXEC-PROC’  identifier  I 
“FUNCTION”  identifier  I 
“PROCEDURE”  identifier  I 
“END” 

structural.entry  ::=  “AUTO-DD”  I  “END-LOC-DD”  I 

“END-MAJOR-HEADER”  I  “END-SYS-DD”  I  “END-SYS-PROC’1 
“END-SYSTEM”  I  “LOC-DD”  I  “MAJOR-HEADER”  I 
“MINOR-DD”  I  “PROGRAM-BODY”  I  “SUBPROGRAM-DD”  I 
“  SYS-DD”  I  “SYS-PROC”  I  “SYSTEM” 
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Part  n  ENCORE-MODEL  Integration  Study 

Task  in  of  this  project  sought  to  study  the  feasibility  of  integrating  GE’s  ENCORE  system 
with  Computer  Command  and  Control  Coiporation’s  (CCCC)  MODEL  system.  The  initial 
phase  of  the  study  compared  the  functionality  of  the  two  systems  to  determine  whether  it 
makes  sense  to  integrate  them.  This  was  followed  with  the  design  of  a  method  for  integrat¬ 
ing  the  two  systems.  As  a  result  of  our  study,  we  have  concluded  that  the  two  systems 
could  functionally  complement  each  other  and  that  there  are  no  insurmountable  technical 
barriers  blocking  the  integration.  The  issues  involved  with  integrating  the  two  systems  are 
discussed  in  the  following  paragraphs. 

The  ENCORE  system  promotes  reuse  of  heritage  code  via  automatic  translation  and 
reengineering.  Components  of  the  ENCORE  system  include  translators  from  FORTRAN  to 
Ada  and  CMS-2  to  Ada,  control  and  data  restructuring,  basic  metric  capabilities,  limited 
dataflow  analysis,  and  the  ability  to  parse  and  regenerate  Ada  programs.  The  restructuring 
components  (control  and  data)  provide  an  automated  mechanism  for  understanding  and 
improving  the  fine  grained  aspects  of  a  software  system.  The  MODEL  system  provides  an 
environment  for  viewing  and  modifying  the  coarse  grained  architectural  features  of  an 
existing  software  system.  Combining  ENCORE  and  MODEL  would  produce  an  environ¬ 
ment  for  reengineering  both  at  the  fine  grained  and  coarse  grained  levels. 

Combining  the  two  systems  would  require  that  they  share  the  information  about  the  code 
being  reengineered.  Currently  both  systems  operate  on  their  own  distinctive  internal  repre¬ 
sentation  of  Ada  code.  (The  ENCORE  internal  representation  is  called  the  IRep  and  the 
MODEL  internal  representation  is  called  the  ESL.)  Since  the  Implementations  of  the  two 
representations  are  vastly  different  and  a  great  deal  of  reengineering  functionality  has 
already  been  developed  specific  to  each  implementation,  we  recommend  a  loose  coupling 
of  the  two  systems  via  translation  between  the  two  internal  representations.  Though  the 
implementations  of  the  two  internal  representations  are  vastly  different,  they  both  embody 
the  same  information  and  the  mapping  from  one  internal  form  to  the  other  appears  to  be 
straightforward. 

This  approach  avoids  the  reimplementation  of  reengineering  capabilities  just  for  a  differ¬ 
ent  internal  representation  and  it  allows  the  two  companies  to  further  develop  their  prod¬ 
ucts  without  having  to  tightly  coordinate  changes. 

The  only  stumbling  point  in  this  integration  scheme  is  a  platform  problem.  The  ENCORE 
system  runs  on  a  UNIX^  platform  and  currently  uses  the  Sun^ew^windowing  system.  The 
MODEL  system  is  tightly  coupled  with  the  DECdesign^  system  and  therefore  must  run  on 
a  VMS  platform.  This  problem  can  be  overcome  by  either  moving  one  system  to  the  other 
platfcmn,  or  creating  a  mechanism  for  passing  the  information  between  the  internal  repre¬ 
sentations  (and  therefore  between  machines)  via  ASCII  files. 


1.  UNIX  is  a  registered  trademark  of  AT&T  Bdl  Laboratories 

2.  SunView  is  a  trademaric  of  SUN  Nficrosystems,  Inc. 

3.  DECdesign  is  a  trademark  of  Digital  Equipment  Corporation 
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If  the  ENCORE  user  interface  were  rewritten  in  X,  then  ENCORE  could  run  on  the  VMS 
platform.  To  move  MODEL  to  a  UNIX  platform,  CCCC  would  have  to  either  get  an  imple¬ 
mentation  of  DECdesign  for  UNIX  or  replace  the  use  of  ESGdesign  in  MOE^  with  some 
other  database  and  visualization  system.  Either  option  involving  MODEL  is  estimated  to 
require  more  effort  than  moving  ENCORE  to  VMS.  We  advocate  changing  the  ENCORE 
user  interface  to  X,  if  integrated  performance  on  a  single  platform  is  required. 

The  alternative  to  changing  platforms  is  to  provide  a  mechanism  for  passing  the  informa¬ 
tion  between  the  two  reengineering  systems  via  ASQI  files.  To  use  the  systems  in  an  inte¬ 
grated  manner,  one  would  follow  the  following  sequence  of  steps:  1)  a  collection  of  Ada 
source  code  would  be  reengineered  using  one  of  the  systems;  2)  ASCII  files  capturing  the 
all  the  necessary  information  would  be  generated  and  passed  to  the  other  system;  3)  the 
other  system  would  be  used  to  further  reenginea'  the  Ada.  (The  passing  of  the  ASCII  files 
would  be  bi-directional.)  When  the  reengineering  is  finished,  new  Ada  code  would  be 
regenerated  capturing  the  reengineering  nradifications  made  by  both  systems.  )^th  this 
scenario,  the  ASCII  files  would  have  to  completely  c£q>turc  all  the  information  in  the  inter¬ 
nal  representations  and  both  systems  would  have  to  be  able  to  parse  and  print  these  ASCII 
files. 

Since  the  internal  representations  for  the  two  systems  currently  contain  the  exact  same 
information  as  is  contained  in  an  Ada  program,  we  have  the  option  of  choosing  either  an 
abstraction  of  one  of  the  internal  forms  or  restructured  Ada  code  for  the  format  of  the 
ASCII  files.  A  shortfall  of  the  latter  option  is  that  it  precludes  future  expansion  of  the  inter¬ 
nal  representations.  We  expect  that  in  the  future  we  will  want  to  expand  MODEL  and 
ENCORE  to  be  able  share  computed  information  about  the  Ada  code.  Using  Ada  code  as 
the  means  of  communication  between  the  two  systems  would  prohibit  this  expansion. 
Therefore  we  recommend  choosing  an  abstraction  of  one  of  the  internal  forms. 

The  ENCORE  system  currently  has  a  prototype  version  of  an  ASCII  file  parser  and  printer 
which  consumes  and  produces  an  abstraction  of  the  IRep.  We  call  this  software  our  IRep 
Inputter/Outputter.  As  mentioned  above,  this  software  is  only  in  prototype  form  at  this 
time,  but  with  ntinimal  effort  it  can  be  extended  to  handle  the  complete  ENCORE  IRep. 
The  software  is  written  in  Ada  and  can  easily  be  integrated  into  both  MODEL  (under 
VMS)  and  ENCORE  (under  UNIX). 

In  summary,  we  are  suggesting  translation  between  the  MODEL  ESL  and  ENCORE  IRep  as 
the  best  way  to  integrate  the  two  systems.  To  accomplish  this  an  ESL  IRq)  translator 
must  be  built  and  either  ENCORE  have  to  be  nx>ved  to  the  VMS  platform,  or  the  IRep 
Inputter/Outputter  will  have  to  be  made  nxne  robust  and  incorporated  into  both  MODEL 
and  ENCORE.  The  following  pages  provide  an  outline  and  estimates  of  the  tasks  involved 
with  each  option. 
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I 

I  Figure  6  illustrates  the  envisioned  system  architecture  for  a  meiged  ENCORE-MODEL  sys- 

tem  where  ENCORE  has  been  mov^  to  the  VMS  platform. _ 


FIGURE  i.  ENCORE  •  MODEL  IntcgratioD  on  a  Conmoa  VMS  Platfonn 


To  realize  the  integration  shown  in  Figure  6,  the  following  tasks  must  be  completed: 

•  Software  must  be  written  to  translate  back  and  fcHth  between  ESL  and  IRep.  (about  9 
person  months  to  complete) 

•The  ENCORE  user  interface  must  be  rewritten  in  X.  (about  9  person  nx>nths) 

•The  ENCORE  and  MOTOL  user  interfaces  must  be  updated  to  allow  the  user  to  switch 
between  the  two  systems  (automatically  transferring  Aom  one  internal  representa¬ 
tion  to  the  other),  (about  1  person  months  •  1/2  person  month  for  each  system) 

We  believe  a  sound  estimate  fOT  this  form  of  integration  is  20  person  months. 
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Figure  7  shows  how  to  integrate  the  two  systems  via  ASCII  IRep  files. 


Sun  woricstation 


nCURE  7.  ENCORE  •  MODEL  lategratkm  via  ASCD  IRep  Files  b 

To  implement  the  above  integration  the  following  must  be  done: 

•Software  must  be  written  to  translate  back  and  forth  between  ESL  and  IRep.  (about  9 
person  months  to  complete)  (This  is  the  same  as  the  first  bullet  with  the  previous 
integration  option.) 

•The  IRep  Inputter/Outputter  must  be  made  more  robust,  (about  3  person  months  to 
complete) 

•The  IRep  Inpuner/Outputter  must  be  incorporated  into  the  MODEL  system:  the  file 
loading  process  must  be  updated  to  load  IRep  files  using  the  Inputter  and  translate 
the  IRep  structure  to  an  ESL  structure,  and  the  file  writing  process  must  be  updated 
to  translate  the  ESL  structure  to  the  IRep  structure  and  generate  the  ASQI  IRep  files 
using  the  Outputter.  (about  2  person  months  to  compete) 

•The  ENCORE  file  load  and  file  write  must  be  updated  to  use  the  IRep  InputterA^utput- 
ter.  (about  1  month  to  complete) 

We  estimate  it  will  take  16  person  months  to  achieve  this  fcnm  of  integration. 
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Appendix  A 

CMS  RET  User’s  Manual 


CMS  RET  User’s  Manual 


1.0  Introduction 

The  CMS  Reverse  Engineering  Ibol  (RET)  consists  of  CMS-Rev  and  Teamworic/SD.  CMS-Rev  has  been 
devekq)ed  by  GE  CR&D  and  provides  the  ability  to  process  CMS-2  source  code  and  create  a  software  main¬ 
tenance  dattd)ase.  This  software  maintenance  databt^  consists  of  a  Tlsamwoik  database  a(  structure  charts, 
module  specs,  data  dictionary  entries  and  collateral  files  which  contain  information  about  die  structure  and 
OMitents  of  the  source  code  being  maintained.  Teamwotk/SD  is  a  commercially  supported  product  availaUe 
ftom  Cadre  Technologies.  It  has  been  augmented  by  user  menus,  shell  scrqNs  and  access  programs  to  pro¬ 
vide  a  customized  and  enhanced  environment  which  utilizes  the  software  maintoiance  riaraha<y-  oeated  by 
CMS-Rev. 

This  CMS  RET  User’s  Manual  describes  the  procedures  for  using  the  RET  software  maintenance  database. 
These  procedures  involve  the  use  of  the  Teamw(»k/SD  product  from  Cadre  Technologies.  The  section  Using 
the  RET  Database  documents  the  basic  operations  that  the  software  maintainer  would  need  to  perform  in 
(Hder  to  utilize  the  software  maintenance  database. 

Also  contained  in  this  manual  are  the  procedures  for  creating  the  RET  software  maintenance  database  using 
CMS-Rev,  related  programs  and  shell  scripts.  These  procedures  are  performed  in  batch  mode  when  neces¬ 
sary  because  of  a  new  release  of  the  source  code  being  maintained,  or  as  a  result  of  new  version  of  CMS- 
Rev.  The  section  Building  the  RET  Database  documents  the  steps  necessary  to  build  a  new  RET  software 
maintenance  database.  The  section  Installing  Ae  RET  Processors  documents  the  steps  necessary  to  install 
CMS  Rev,  related  programs  and  shell  scripts  before  beginning  the  process  of  building  a  new  RET  database. 


2.0  Using  the  RET  Database 

2.1  Invoking  RET 

RET  is  invoked  by  executing  Teamwork  using  the  RET  configuration  file.  This  can  be  accomplidied  by 
manually  typing  the  Teamwork  command  or  by  selecting  the  apprcqniate  menu  item  ftom  an  Openllifindows 
workplace  menu.  The  user  then  interacts  with  Teamwork  to  access  the  RET  software  maintenance  database. 
The  RET  configuration  file  provides  the  user  with  access  to  the  customized  RET  menus  and  to  the  special¬ 
ized  programs  which  access  the  RET  software  maintenance  database. 

A  number  of  setup  operations  need  to  be  performed  before  RET  can  be  invoked:  (1)  Modify  the  Unix  PATH 
variable  to  include  the  Teamwork  directories.  (2)  Initialize  the  Unix  envirorunent  variable  RET_DB_HOME 
to  qiecify  the  RET  root  directory.  (3)  Verify  that  the  Teamwork  DC  server  is  running  cm  the  Teamwork 
workstation  server. 


2.2  Using  the  Online  Help 

Each  of  the  RET  menus  has  a  menu  selection  titled  “Display  Help  Screen”  that  is  the  last  sdection  on  the 
menu.  Selecting  this  menu  item  will  cause  the  context  sensitive  help  screen  to  be  displayed  in  a  Tbamwork 
window.  In  addition  to  a  description  of  each  menu  item  availaUe  to  the  user,  there  may  sppcu  hints  to  the 
user  on  how  to  perfram  specific  operations. 
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23  Selecting  the  Model  of  Interest 


The  first  operation  that  the  user  must  perform  is  to  select  the  model  of  interest  Any  further  operations  wiU 
then  pertain  to  is  model  which  conesponds  to  a  Unix  directory. 

The  model  of  interest  is  selected  by  pulling  down  the  Index  menu  firom  the  desktop  menubar,  and  selected 
the  menu  item  titled  “Open  Model  Index.”  This  will  cause  a  list  of  the  models  in  the  Ibamwork  database  to 
be  di^layed.  Highlight  the  model  of  interest  and  select  “Open  PT  from  the  puUright  menu.  The  Ibamworic 
{vocess  index  for  the  selected  model  will  be  di^layed.  From  this  process  index  witulow.  the  user  may  access 
structure  charts,  noodule  specs,  and  the  data  dictionary  associated  with  the  selected  model 


2.4  Navigating  Structure  Charts 

Structure  charts  provide  a  graphical  representatioi  of  the  calling  relationships  between  software  modules. 
The  structure  chart  can  be  used  as  a  “map”  to  guide  the  software  maintainer  in  his^r  understanding  the 
underlying  software.  Off-page  connectms  are  used  in  structure  charts  so  that  the  amount  of  infmmation  on  a 
given  structure  chart  is  not  excessive.  The  intent  is  to  maintain  readability  when  RET-generated  structure 
charts  are  printed  on  8  1/2  by  11  inch  pages. 

To  navigate  downward  in  the  module  calling  hierarchy  using  structure  charts,  the  user  may  open  the  struc¬ 
ture  charts  for  a  specified  off-page  connectcv.  This  is  accomplished  by  selecting  the  off-page  connects  with 
the  mouse  select  button  (left  mouse  button),  pulling  down  ^  RET  menu  firom  the  structure  chart  menubar 
and  selecting  the  menu  item  titled  “Expand  OMmectm.”  The  structure  chart  for  the  off-page  coimector  will 
then  be  displayed. 

To  navigate  upward  in  the  module  calling  hierarchy  using  structure  charts,  the  user  may  request  to  display  a 
list  of  modules  which  call  the  current  module.  The  current  module  is,  by  default,  the  m^ule  at  die  top  of  the 
strucuire  chart  The  user  may  override  this  default  module  by  explicitly  selectirtg  another  module  on  the 
structure  chart  as  current  The  list  of  calling  modules  is  obtained  ^  pulling  down  the  RET  menu  from  the 
structure  chart  menubar,  and  selecting  the  menu  item  titled  “Di^Iay  Calling  Modules.”  This  will  cause  a  file 
window  to  open  with  a  listing  of  calling  modules.  Any  line  of  this  file  di^lay  nuiy  be  selected  to  request  the 
structure  chm  for  that  calling  module  by  pulling  down  the  RET  menu  from  the  file  menubar  and  selecting 
the  menu  item  titled  “Open  Structure  Chart”  The  structure  chart  for  the  selected  calling  module  will  then  be 
displayed.  (NB:  this  is  not  currendy  wmldng.  Workaround:  choose  “Open  Module  Spec”  firom  the  RET 
menu  and  then  choose  “Show  SC”  from  the  Whole.M^iec  menu). 

During  the  search,  an  icon  is  displayed  with  the  title  “CALL.”  This  icon  will  disqipear  when  the  search  is 
completed,  and  at  that  time  a  Teamwork  window  will  display  the  results  of  the  search.  The  “Di^lay  Calling 
Modules”  request  may  be  aborted  using  the  normal  Unix  window  inucedure  to  quit  a  task  represent^  by  the 
CALL  icon. 


2.5  Selecting  the  Module  of  Interest 

A  module  is  a  CMS-2  subprogram.  Modules  are  identified  by  the  RET  and  a  module  spec  is  created  for  each 
module.  In  addition,  the  bmes  on  structure  charts  are  used  to  represent  modules. 

Modules  are  listed  on  the  process  index  which  is  displayed  when  the  model  of  interest  is  selected.  The  pro¬ 
cess  index  lists  the  module  qiecs  and  structure  cham  that  are  contained  in  die  Ibamwork  database.  The 
module  of  interest  may  be  selected  firom  the  process  index,  and  then  either  a  module  spec  or  a  structure  chart 
may  be  opened.  Each  process  index  entry  has  a  SC  cnr  MS  indicated.  SC  refers  to  structure  chart  and  MS 
refers  to  module  spec.  A  structure  chart  may  be  qiened  by  selecting  a  module  name  flagged  with  mi  SC, 
pulling  down  RET  firom  the  process  index  menubm  and  selecting  the  menu  item  titled  “Open  Structue 
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Chart”  A  module  q;iec  may  be  (q)ened  by  sdecting  a  module  name  flagged  with  an  MS,  pulling  down  RET 
from  the  [Rocess  in^x  mombar  and  sel^ting  the  menu  item  titled  “Open  Module  Spec.” 

Structure  charts  show  the  calling  relationsh^  betweoi  modules.  Tbe  module  of  interest  may  be  selected 
from  a  structure  chart  by  pointing  the  mouse  curscr  at  the  structure  chart  that  iqiresmits  die  module  of  intm^- 
est  and  pressing  the  select  mouse  button  (left  mouse  button).  Then,  the  user  may  pull  down  the  RET  menu 
from  the  structure  chart  menubar  and  select  the  desired  menu  item.  The  module  al  interest  may  be  selected 
from  a  module  qiec  by  sdecting  the  text  in  the  module  qtec  body  which  is  the  name  of  the  module  of  itun^- 
esL  Text  in  the  module  spec  body  is  selected  by  moving  die  mouse  cursor  on  top  of  die  first  letto’  in  the  text 
string.  The  mouse  cursor  should  turn  from  an  arrow  into  a  Mock.  The  select  mouse  button  Odt  mouse  but¬ 
ton)  is  then  {sessed  and  the  mouse  cursor  is  dragged  across  the  letters  of  the  text  string.  The  selected  text 
will  appeal  in  reverse  video.  Then,  the  user  may  pull  down  the  RET  menu  frmn  the  module  ^lec  menubar 
and  sdect  the  desired  menu  item. 


2.6  Determining  Module  Interfaces 

A  module  interface  is  a  relationship  between  modules  where  one  module  calls  the  other  module.  Module 
interfaces  are  represented  graphically  by  structure  charts,  and  textually  by  information  in  module  spec  bod¬ 
ies.  Module  interfaces  may  be  obtained  by  displaying  the  ^)|Hopriate  structure  chart  or  module  spec.  Rmn  a 
module  qiec.  the  user  may  open  a  TeamwcHk  window  fm'  the  structure  chart  containing  the  module  qiec. 
This  is  accomplished  by  pulling  down  the  Whole.Mqiec  menu  from  the  module  qpec  menubar,  and  select- 
irtg  the  menu  item  titled  “Show  SC.”  This  will  cause  the  apimqiriate  strucuire  chart  to  be  di^iayed. 


2.7  Viewing  Module  Source  Files 

Module  source  files  are  the  raw  CMS  source  files.  Module  source  files  may  be  displayed  by  selecting  the 
module  of  interest  from  a  structure  chart,  or  from  a  module  spec  body.  Then,  the  RET  moiu  item  titled  “Dis¬ 
play  Module  Source”  may  be  selected  to  complete  the  request  for  a  Teamwork  file  window  to  be  cqiened  on 
the  taw  source  file. 

An  important  distinction  to  remember  is  that  the  name  of  a  module  is  not  necessarily  the  same  as  the  name  of 
the  source  file  containing  the  module.  The  boxes  on  structure  charts  and  the  “calls”  and  “called  by”  section 
of  the  module  qiec  body  all  use  module  names,  not  file  names. 


2.8  Searching  Source  Files  for  Text 

A  facility  for  searching  raw  sounce  files  has  been  built  into  RET.  This  facility  is  available  from  the  process 
index  menubar.  The  user  selects  the  model  of  interest  and  opens  the  tqiproiRiate  Ibamworir  process  index 
window.  The  user  then  pulls  down  the  RET  menu  from  the  process  iridex  menubar,  and  sdects  the  menu 
item  titled  “Search  Source  Files.”  This  causes  a  Teamwork  irqiut  window  to  be  di^layed  which  requests  the 
user  to  input  the  filename  and  text  patterns.  The  filename  pattern  is  a  standard  Unix  filename  pattmn,  includ¬ 
ing  the  use  (tf  ?  and  *  for  wildcards.  The  text  pattern  is  a  grqi  regular  expression,  which  needs  to  be  enclosed 
within  either  single  ot  double  quotes  if  the  text  pattern  contains  qiecial  charactns. 

After  the  filename  and  text  patterns  are  input,  a  Unix  task  is  invoked  to  perform  the  search  on  the  source 
files.  During  the  search,  an  icon  is  diqilay^  widi  the  title  “SCH.”  This  icon  will  disaiqiear  when  the  search 
is  completed,  and  that  time  a  Ibamw^  window  will  display  the  results  of  the  search.  The  “Search  Source 
Hies”  request  may  be  aborted  using  the  normal  Unix  window  procedure  to  quit  a  task  rqnesented  by  the 
SCH  icon. 

Source  files  may  also  be  searched  across  all  CSCIs.  This  is  accomplished  using  die  “Sevch  Source  Hies” 
menu  item  on  die  RET  menu  of  the  Teamwork  desktop  menubar. 
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2.9  Selecting  the  Global  Variable  of  Interest 


Global  variables  are  variables  which  are  used  outside  of  the  module  in  which  they  are  declared.  These  global 
variables  are  listed  alphabetically  within  the  data  dictionary  for  each  model,  and  also  as  part  of  the  module 
q)ec  fw  modules  which  reference  the  global  variable.  The  data  dictionary  is  di^layed  for  die  model  of  inter¬ 
est  by  pulling  down  the  “Whole.Model”  menu  firom  the  process  index  menubar,  and  selecting  the  omhu  item 
titled  “Open  DD.”  This  will  cause  the  requested  data  dictionary  to  be  di^layed.  The  global  vatiaUe  of  inter¬ 
est  may  be  selected  from  this  display  of  the  data  dictionary  by  moving  the  mouse  curstx'  to  the  desired  line  of 
the  dam  dictionary  and  pressing  the  selea  mouse  button  Oeft  mouse  button). 

When  a  module  spec  is  di^layed,  the  global  variaUes  listed  may  also  be  selected  as  the  global  vmiable  of 
interesL  This  is  accomplished  by  moving  the  mouse  cursor  on  tqi  of  the  first  characto’  of  the  name  of  the 
global  variable.  The  mouse  cursor  will  change  firom  an  arrow  to  a  block.  The  user  presses  the  mouse  selea 
button  (left  mouse  button)  and  drags  the  cursa  across  the  global  variable  name  untU  all  the  charactos  are  in 
reverse  video.  At  this  point,  the  global  variaUe  of  interest  on  the  module  qiec  has  been  sdected. 

2.10  Viewing  Data  Dictionary  Definition  of  Global  Variables 

The  data  dictionary  contains  an  entry  for  each  global  variable.  This  entry  contains  information  about  the  glo¬ 
bal  variable,  including  the  actual  declaration  of  the  global  variable,  and  infomation  about  the  raw  or 
expanded  source  files.  The  declaration  contains  the  type  of  the  variable  if  the  variable  is  an  item.  If  the  vari¬ 
able  represents  a  table,  then  the  declaration  contains  infonnation  about  the  types  of  the  items  in  the  taMe. 

When  a  global  variable  of  interest  has  been  identified  from  the  data  dictionary  display,  then  the  RET  menu 
from  the  data  dictionary  menubar  is  pulled  dovm,  and  the  menu  item  titled  “Open  DDE”  is  selected.  This 
will  cause  the  data  dictionary  entry  to  be  displayed.  When  the  global  variable  of  interest  has  been  identified 
from  the  module  spec  display,  then  the  RET  menu  from  the  module  ^qiec  menubar  is  pulled  down,  and  the 
menu  item  titled  “Open  DDE”  is  selected.  This  will  cause  the  data  dictionary  entry  to  be  di^layed. 

A  data  dictionary  entry  may  reference  other  data  dictionary  entries.  This  h^ipens  when  the  global  variable 
represents  a  table  or  a  Mock.  In  these  cases,  the  name  of  the  referenced  data  dictionary  entry  may  be  selected 
and  the  RET  menu  may  be  pulled  down  from  the  data  dictionary  entry  menubar,  and  the  menu  item  titled 
‘X)pen  DDE”  selected.  This  will  cause  the  selected  data  dictionary  entry  to  be  displayed  in  a  new  data  dictio¬ 
nary  entry  window. 

2.11  Searching  Module  Specs  for  Variable  References 

Global  variables  are  associated  with  modules,  and  their  module  qpecs.  A  csqiability  exists  to  perform  a 
search  fw  the  modules  which  reference  a  particular  global  variaMe.  This  search  is  performed  when  the  user 
selects  a  global  variable  of  interest,  Etom  either  the  data  dictionary  or  a  module  ^wc,  pulls  down  the  RET 
menu  firom  the  respective  menubar,  and  selects  the  menu  item  titled  “Di^lay  Whoe  Ref.” 

After  the  global  variable  cross  reference  is  initiated,  a  Unix  task  is  invented  to  perform  the  search  within  the 
Teamwork  database.  During  the  search,  an  icon  is  displayed  with  the  title  “R^.”  This  icon  will  disappear 
when  the  search  is  completed,  and  at  that  time  a  Teamwmk  window  will  display  the  results  of  the  sei^. 
The  “Di^lay  Where  ReP  request  may  be  aborted  using  the  normal  Unix  window  procedure  to  quit  a  ta^ 
represent^  by  the  REF  icon.  Module  specs  for  modules  identified  in  the  cross  reference  diqilay  may  be  dis¬ 
played  by  sel^ting  the  name  (tf  the  module  in  the  cross  reference  display,  pulling  down  the  RCT  menu  firom 
the  file  moiubar,  and  selecting  the  menu  item  titled  “Show  Module  Spec.”  This  will  cause  the  reflective 
module  spec  to  be  difilayed. 
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Global  variaUe  cross  references  may  also  be  perfomed  across  all  CSCIs.  This  is  accom[dislied  using  the 
“Di^lay  Where  All'’  menu  item  on  the  RET  menu  of  the  data  dictionary  or  module  qiec  menubar. 

2.12  Printing  From  the  RET  Database 

The  user  may  obtain  printouts  of  the  process  index,  the  data  dictionary  index,  structure  charts,  module  qiecs, 
data  dictionary  entries,  any  Tbamwo^  file  window  that  has  been  opened,  and  any  expanded  module  source 
file. 

2.13  Terminating  Teamwork 

BefcMC  terminating  Teamwwk,  be  sure  that  all  Teamwmk  windows  have  been  closed.  Then,  pull  down  the 
“Stq;)’’  menu  fiom  the  desktop  menubar  and  select  the  menu  item  titled  “Quit”.  This  will  terminate  the  cur¬ 
rent  Teamwo'k  session. 


3.0  Building  the  RET  Database 

3.1  CMS  Rev  Processor 

CMS  Rev  consists  of  three  (3)  separate  passes.  These  pa.sses  combine  to  process  the  CMS-2  code,  to  process 
the  comments  and  to  generate  the  output  files  used  to  create  the  RET  software  maintenance  database.  The 
CMS  Rev  processor  can  be  executed  using  the  shell  script  called  build-ret  which  is  listed  in  the  last  section 
(Details  of  Setup).  This  shell  script  takes  care  of  deleting  old  versions  of  the  build  log  files,  and  allows  the 
user  to  monitor  its  execution  with  time  and  date  stamped  messages  informing  the  user  of  what  pass  is  cur¬ 
rently  being  executed.  The  file  $RET_DB_HOME/srcA;sci-build  is  used  to  determine  which  (}SCIs  are 
being  processed  by  CMS  Rev  in  the  current  execution. 


3.2  CMS  Rev  Post-Processors 

The  CMS  Rev  post-processors  augment  the  processing  perfumed  by  C^S  Rev.  Two  operations  are  per¬ 
formed:  (1)  mo^y  some  CMS  Rev  output  files  befue  they  can  be  used  by  the  RET  interactive  programs, 
and  (2)  analyze  some  CMS  Rev  intermediate  ouqwt  files  to  create  additional  ouqnit  files  for  use  by  the  RET 
interactive  programs.  This  CMS  Rev  post-processing  has  been  combined  into  a  shell  scr^  called  build-twk. 
This  shell  script  should  be  executed  once  fu  each  CSCl. 

3.3  C  Rev  and  twk_put  Processors 

The  C  Rev  and  twk_pot  processors  are  Team woik  programs  which  are  used  to  load  the  Teamwuk  data  base. 
C  Rev  uses  CMS  Rev  output  to  create  structure  charts  in  the  Teamwork  database.  twk_put  uses  CMS  Rev 
ouQHit  to  create  both  module  specs  and  data  dictionary  entries  in  the  Teamwork  database.  A  shell  script 
called  retscript  is  created  by  CMS  Rev  to  be  used  in  loading  the  Teamwork  database. 
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4.0  Installing  the  RET  Processors 

4.1  Teamwork  Processors 

The  Cadre  Teamwcxk  products  that  must  be  installed  include  Teamwok/SD  and  Ibamwotfc/C  Rev.  The 
Teamwwk/C  Rev  Browser  is  not  needed  by  die  RET. 


4.2  CMS  Rev  Processors 

The  CMS  Rev  {Mocessors  consists  of  multiple  passes  as  follows:  cms2cdif.p3,  cms2cdif.p4a,  cms2cdif.p4b, 
and  cms2cdif.p^.  These  executaUe  programs  should  be  installed  before  CMS  Rev  can  be  used  to  build  die 
RET  database. 

4.3  CMS  Rev  Post-Processors 

The  CMS  Rev  post-process(vs  consists  of  the  following  {Hograms; 

build-ret 

build-twk 

build-csc 

do-errors 


5.0  Details  of  Set-up 

5.1  Environment  Variables 

There  is  on  major  environment  variable  which  must  be  set  before  running  RETi 

RET_DB_HOME  -  the  directory  in  which  all  the  executables  and  shells  live 


5.2  Scripts  (preliminary  versions) 

There  are  several  scripts  which  are  useful  in  running  RET  (although  it  can  be  run  manually).  These  scripts 
can  be  found  in  RET_DB_HOME/admin,  and  they  are  as  follows: 

bitild-ret-  a  multi-function  script  vdiich  asks  for  user  direction  upon  invocation.  It’s  currem 
functions  are:  CMS  Rev  Pass3;  CMS  Rev  Comment  Extraction;  CMS  Rev  Pass4; 
Post-Process  CMS  Rev,  Creme  Ibamwork  Database;  Dump  Tbamwrak  Database;  and 
Resttxe  Teamwork  Daudiase.  The  user  is  encouraged  to  review  die  scrqM  in  rader  to 
get  an  understanding  how  RET  is  put  together. 

go-rti  -  a  script  which  invokes  Cadre  Ibamwork  with  the  ptopo'  configuration  file.  etc. 


S3  Directories 

There  are  two  directories  which  the  user  should  set  iq>  for  each  model.  The  first  is  $RET_DB_HOME/src/ 
model_name.  This  directary  should  contain  the  source  files  for  the  model.  (This  may  be  a  soft  link,  if  it 
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proves  convenient)  The  second  directory  is  $RET_DB_HOME/Ist/inK)del_nanie.  This  should  be  created  as 
an  empty  directory.  CMS  RET  places  files  in  there  during  its  processing. 


5.4  Files 

Thne  are  two  files  whkh  the  user  may  wish  to  igxlate.  They  are  $RET_DB_HOME/dat/csci-build  and 
$RET_DB_HOME/dat/csci-names.  These  are  mxmally  not  needed  for  RET,  but  can  be  useful  fw  rdHiilding 
the  entire  system  via  build-ret  They  should  contain  the  model  names  for  the  system,  one  per  line. 

There  is  one  file  which  the  user  must  add  to  the  $RET_DB_HOME/srcAnodel_name  directory:  iimits.txL 
This  file  should  have  exactly  one  line  in  it  which  says  “do  globals”. 
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Introduction  to  the  ENCORE  Internal 
Representation 


The  Purpose  of  the  Internal  Representation. 

The  purpose  of  the  ENCORE  Internal  Representation  (or  IRep,  for  short),  is  to  allow  the 

various  tools  in  ENCORE  to  manipulate  Ada  programs  in  a  straightforward  and  uniform 

way. 

Some  goals  in  the  IRep  design  were: 

1.  There  should  be  a  logical  abstract  description  of  the  IRep. 

2.  The  IRep  should  be  accessible  via  a  logical  interface  that  is  independent  of  the  physical 
representation  of  the  IRep  in  memory. 

3.  There  should  be  a  clean  separation  between  lexical  information  and  semantic  informa¬ 
tion. 

4.  One  should  be  able  to  reconstruct  the  original  source  to  an  Ada  program  from  the  IRep 
(modulo  differences  in  formatting). 


The  Logical  Structure  of  the  Internal  Representation 

Logically,  the  IRep  is  a  tree,  with  some  backlinks  for  handling  references  to  definitions 
and  labels,  and  symbol  table  structures  to  capture  Ada  programs.  (The  tree  structure  is 
quite  similar  to  DIANA,  the  standard  internal  representation  for  Ada.)  Each  tree  repre¬ 
sents  the  statements  in  the  Ada  code  and  the  symbol  tables  represent  the  scoping  and  visi¬ 
bility  rules  for  the  identifiers  found  in  the  code. 


The  IRep  Program  IVee 

The  tree  structure  consists  of  ‘nodes’  and  ‘attributes.’  The  nodes  represent  the  informatimi 
in  the  tree,  while  the  attributes  represent  the  edges  of  the  tree. 

The  nodes  are  grouped  into  ‘classes,’  each  class  corresponding  to  a  kind  of  Ada  construct. 
The  attributes  are  also  grouped  into  named  classes.  As  an  example,  consider  the  class  of 
nodes  ccnresponding  to  Ada  assignment  statenoents.  Each  such  node  must  belong  to  the 
class  ‘assignment.stmt’  FurthemKve,  each  such  node  must  have  two  attributes  ~  one 
called  ‘target,’  representing  the  destination  of  the  assignment,  and  the  other  called 
‘source,’  representing  the  expression  to  be  assigned. 
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1.  ADL:  The  Metalanguage  Used  to  Describe  the  IRep  Trees 


The  IRep  tree  is  specified  in  a  metalanguage  called  the  Augmented  Description  Language, 
or  ADL,  for  short 

An  ADL  description  consists  of  a  series  of  ‘productions.’  The  productions,  in  turn,  can  be 
of  the  following  lands:  stub  productions,  primitive  productions,  node  productions,  and 
class  productions. 

1.1  Stub  Productions 
Stub  productions  have  the  syntax 
stub  <name> ; 

These  productions  are  used  to  define  certain  special  nodes  that  are  used  in  processing  Ada 
programs.  There  are  exactly  two  stub  productions 

stub  Empty; 
stub  Undefined; 

The  first  production  defines  the  ‘empty’  node,  which  is  generallv  used  to  an  optional 
attribute  that  is  not  supplied  (for  example,  a  missing  ‘else’  clause  in  an  ‘if  statement.  The 
second  production  generally  indicates  either  an  error  condition  or  an  unsuccessful  opera¬ 
tion.  For  example,  the  value  returned  by  an  unsuccessful  symbol  table  search  is  the  ‘unde¬ 
fined’  node. 

12  Primitive  Productions 
Primitive  productions  have  the  syntax 
primitive  <name>; 

Primitive  productions  are  used  to  define  external  data  types  that  are  used  as  data  at  the 
leaves  of  Ae  IRep  trees.  The  actual  productions  used  in  the  Ada  IRep  tree  are 

primitive  Boolean; 
primitive  Character, 
primitive  Float; 
primitive  Integer, 
primitive  String; 
primitive  Symbol; 

The  first  five  productions  correspond  to  the  five  predefined  scalar  types  in  the  Ada  pack¬ 
age  Standard.  The  sixth  production,  ‘Symbol,’  cmiesponds  to  the  type  ‘Symbol,’  defined 
in  the  package  ‘IForm.Symbols.’  This  Symbol  type  is  used  to  represent  Ada  identifiers. 
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U  Node  Productioiis 


Node  productions  have  the  form 

<name>  =>  <attrl-name> :  <attrl-descriptoi>, 

<attr2-name> :  <attr2-descriptor>, ... ; 

Node  productions  describe  the  internal  structure  of  an  IRep  tree.  The  left  hand  side  of  a 
node  production  indicates  the  class  of  the  node  involved,  while  the  right  hand  side  gives 
the  names  and  attributes  of  a  node  of  that  class. 

Attributes  can  be  either  simple  attributes,  whose  value  is  a  node,  or  sequence  attributes, 
whose  value  is  a  sequence  of  nodes.  Simple  attributes  have  the  form 

<class-name> 

while  sequence  attributes  have  the  form 
seq  of  <class-name> 

An  example  of  a  node  production  having  simple  attributes  is  given  by  the  production  fOT 
an  Ada  assignment  statement,  which  is  written 

assignment.stmt  =>  source :  EXP, 

target :  REFERENCE; 

This  production  states  that  each  node  of  tiie  class  ‘assignment.stmt’  has  two  attributes,  a 
‘source’  attribute,  whose  value  must  be  of  class  ‘EXP,’  and  a  ‘target’  attribute,  whose 
value  must  be  of  class  ‘REFERENCE.’ 

As  an  example  of  sequence  attributes,  consider  the  production  for  an  Ada  else  clause, 
which  is  written 

else.clause  =>  statements  :  seq  of  STMT; 

This  production  says  that  each  node  of  class  ‘else.clause’  has  the  attribute  ‘statements,’ 
whose  value  is  a  sequence  of  nodes  of  class  STMT. 

One  final  note.  It  is  possible  that  a  particular  class  of  IRep  tree  node  might  not  have  any 
attributes.  An  example  is  the  class  of  node  that  represents  ‘null’  statements  in  Ada.  The 
production  for  this  class  is  written 

nulLstmt  => ; 

We  use  a  node  production,  rather  than  a  stub  or  primitive  production  because 

1.  there  can  be  iiKHe  than  one  node  of  class  ‘nulLstmt’  in  an  IRep  tree  structure,  which 
rules  out  using  a  stub  production,  and 
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2.  the  class  *null_stmt’  is  not  imported  firom  another  package,  which  rules  out  using  a 
primitive  production. 


Class  Productions 


Qass  productions  have  the  form 

<:class-name>  ::=  <subclassl>  I  <subclass2>  I ... ; 

The  classes  on  the  right  hand  side  of  the  production  are  called  subclasses  of  the  class  on 
the  left  hand  side. 

Qass  productions  are  used  for  two  purposes: 

1.  To  group  certain  classes  together  in  a  manner  similar  to  union  types  in  some  program¬ 
ming  languages,  and 

2.  To  enable  several  classes  to  inherit  one  or  nnore  attributes. 

A  production  that  satisfies  the  first  purpose  is 

ACTUAL_COMPONENT  ::=  association  I  others_part  I  EXP; 

This  production  says  that  a  node  of  class  ‘ACTUAL_COMPONENT’  can  be  either  of 
class  ‘association,’  class  ‘othcrs_part,’  or  class  ‘EXP.’  Thus  the  node  production 

aggregate  =>  components  :  seq  of  ACTUAL_COMPONENT; 

indicates  that  a  node  of  class  ‘aggregate’  has  an  attribute  called  ‘components,’  which  can 
take,  for  its  value,  a  sequence  of  nodes,  each  member  of  which  must  be  either  an  ‘associa¬ 
tion,’  an  ‘othcrs_pan’,  or  an  ‘EXP.’ 

To  illustrate  the  second  purpose  of  class  productions,  suppose  we  have  several  different 
kinds  of  nodes  that  possess  a  given  attribute.  In  Ada,  for  example,  package  specifications, 
package  bodies,  procedure  specifications,  procedure  bodies,  etc.  all  have  an  attribute 
called  ‘designator,’  which  denotes  the  name  of  the  unit.  Rather  than  include  a  separate 
‘designator’  attribute  in  each  node  production,  we  could  write  the  two  following  produc¬ 
tions: 

SINGLE_DESIGNATOR_ITEM  =>  designator :  Symbol; 

SINGLE_DESIGNATOR_i  l  tM  ::*  pkg_spec  I  pkg_bdy  I  proc_spec  I ... ; 

The  attribute  ‘designator’  will  then  be  inherited  by  all  subclasses  of  the  class 
‘SINGLE_DESIGNATOR_ITEM.‘ 
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2.  The  External  Representation  of  IRep  T^ee  Structures 

Externally,  IRep  tree  structures  are  represented  as  one  or  more  node  structures.  Node 
structures  are  represented  differently,  depending  on  the  kind  of  node  involved. 

1.  Stub  nodes  are  represented  by  the  name  of  the  stub  class;  thus  the  two  stub  nodes  in  the 
Ada  IRep  tree  are  represented  by 

Eiiq)ty 

and 

Undefined 

2.  Primitive  nodes  are  represented  by  the  class  name,  followed  by  the  primitive  value, 
enclosed  in  parentheses.  Some  examples  are 

Boolean(TRUE) 

Integer(3) 

Float(5.38) 

Character(‘a’) 

String(“Abc”) 

Symbol(“ABC”) 

3.  Structure  nodes  may  be  represented  by  the  class  name,  followed  by  the  attribute  names 
and  values,  enclosed  within  square  brackets.  An  example  is 

assignment_stmt[taiget  n_103'', 
source  Integer(3)] 

4.  A  structure  node  may  be  preceded  by  a  label.  This  indicates  that  the  node  can  appear  as 
an  attribute  in  more  than  one  place  in  an  Ada  IRep  tree.  An  example  is 

n_103;  named_ref[designator  Symbol(“x”), 
target  n_102''] 

5.  Finally,  a  labeled  node  can  be  represented  simply  by  its  label,  followed  by  a  caret,  as  in 
the  reference  n_102'^  in  the  previous  example.  This  allows  us  to  represent  circular  data 
structures  in  a  linear  ASCII  form. 

3.  The  Ada  Interface  to  the  Internal  Representation 

The  interface  to  the  Ada  IRep  tree  is  provided  by  three  packages;  AdaTran_Records, 
Primitive_Node_Creation,  a  Primitive_AdaTran_Inteiface.  The  package 
AdaT  an.Records  contains  the  definition  of  IRep  tree  nodes  and  sequences;  the  package 
Primitive_Node_Creation  provides  functions  for  building  IRep  tree  nodes;  and  die  pack¬ 
age 

Primitive_AdaTran_Intetface  provides  functions  for  accessing  and  changing  the  value 
of  the  attributes  of  nodes. 
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3.1  The  Package  AdaTran_Records 

The  package  AdaTran_Records  contains  the  following  definitions. 

3.1.1  The  lype  AdaTlran_Node_Kind 

The  type  AdaTran_Node_Kind  is  an  enumerated  type  that  is  used  to  indicate  the  class  of 
any  given  IRep  tree  node.  The  definition  is 

type  AdaTran_Node_Kind  is  (k.UNDEFINED, 
k_EMPTY. 

--  Primitive  Node  Qasses 

k.Boolean, 

k_Character, 

k_Roat, 

k_Integer, 

k_String, 

k_Symbol, 

~  Structured  Node  Qasses 

k_ABORT. 

k_ACCEPT, 


k.WTTH.ELEM); 

Note  that  the  names  of  the  various  node  kinds  are  all  prefixed  with  ‘k_.’  This  avoids  any 
clashes  with  Ada  reserved  words.  For  example,  ABORT  and  ACCEPT  would  class  with 
the  reserved  words  'abort*  and  ‘accept’  in  Ada,  unless  we  modified  them  somehow. 


3.1.2  The  lype  AdalVan_Node 

The  type  AdaTran_Node  corresponds  to  the  IRep  tree  nodes  for  Ada.  It  is  implemented  as 
a  pointer  to  a  record,  which  contains  all  the  attribute  information  for  the  node.  Thus,  we 
have  the  definition 

type  AdaTran_Node_Implementation(Kind  :  AdaTran_Node_Kind)  is 
record 

end  record; 

and  the  definition 

type  AdaTran_Node  is  access  AdaTlran_Node_Implementation; 
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3.U  The  lype  Seq_Of_Ada'n*an_Node 


The  type  Seq_Of_AdaTran_Node  corresponds  to  sequences  of  AdaTran  nodes.  It  is  cre¬ 
ated  by  instantiating  the  generic  package  SEQ  on  the  type  AdaThui_Node.  Thus,  we  have 
the  three  definitions 

package  AdaTran_Node_Seqs  is  new  SEQ(AdaTran_Node,  Eq,  Equal); 

subtype  Seq_Of_AdaTran_Node  is  AdaTran_Node_Seqs.Seq; 

function  New_Seq_Of_AdaTran_Node  return  Scq_Of_AdaTran_Node 
renames  AdaTran_Node_Seqs.New_Seq; 

The  generic  package  SEQ  provides  a  set  of  routines  for  creating  and  manipulating  linked 
lists.  Instantiating  this  generic  package  for  the  type  AdaTVan_Node,  makes  these  opera¬ 
tions  available  for  use  on  nodes.  In  order  to  use  diese  operations  on  sequences  of  AdaTr- 
an_Node(s),  it  is  necessary  to  insert  the  clause 

use  AdaTran_Node_Seqs; 

in  the  declaration  part  of  the  unit  that  uses  these  routines. 

The  subtype  Seq_Of_AdaTran_Node  corresponds  to  sequences  of  nodes. 

The  function  New_Seq_Of_AdaTran_Nodc  returns  the  empty  sequence. 

3.1.4  The  Functions  Eq  and  Equal 

In  dealing  with  a  complicated  structures,  like  AdaTran_Node(s),  it  is  sometimes  necessary 
to  make  a  distinction  between  equivalence  and  identity  in  con^aring  nodes.  The  function 
Eq,  defined  by 

function  Eq(x,  y  :  AdaTran.Node)  return  Boolean; 

returns  true  if  and  only  if  x  and  y  are  the  same  node.  On  the  other  hand,  the  function  Equal, 
defined  by 

function  Equal(x,  y  :  AdaTran.Node)  return  Boolean; 

returns  true  if  and  only  if  x  and  y  are  equivalent  In  this  case  we  require  that  x  and  y  be  of 
the  same  class  and  that  all  the  corresponding  attributes  of  x  and  y  be  Eq. 

3  J  The  Package  Primitive_Node_Creation 

The  package  Primitive_Node_Creation  provides  functions  for  constructing  new  nodes. 
These  consist  of  the  generalized  node  creation  functions,  the  functions  for  building  primi¬ 
tive  nodes,  and  the  functions  for  building  structured  nodes.  A  node,  cmce  created,  can  be 
stored  in  the  node  data  base  (a  table  in  memory  that  holds  AdalVan  nodes  with  symbols  as 
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the  keys).  The  user  can  even  specify  the  name  under  which  the  node  should  be  stored.  This 
data  base  is  meant  to  provide  unique  names  for  all  nodes  that  are  attributes  of  two  or  moTB 
other  nodes.  Many  of  the  node  creation  functions  have  a  parameter  called  ‘Label’  or 
‘Node_Label,’  which  defaults  to  The_Symbol_Undefined.  If  the  user  does  not  specify  a 
name,  the  system  will  generate  one.  if  necessary. 

3,2.1  The  Generalized  Node  Creation  Functions 

The  generalized  node  creation  functions  are 

function  Raw_AdaTran_Node(Kind :  AdaTran_Nodc_Kind) 
return  AdaTran_Node; 


and 


function  New_AdaTran_Node(Kind :  AdaTran_Node_Kind; 

Label :  Symbol  :=  The_Symbol_Undefined) 
return  AdaTran_Node; 


The  function  Raw.AdaTran.Node  simply  creates  a  new,  uninitialized  instance  of  an 
AdaTran_Node.  It  will  rarely  be  used  by  the  programmer,  however,  since  it  is  at  a  very 
low  level  and  requires  that  the  programmer  devote  considerable  attention  to  low-level 
details. 

The  function  New_AdaTran_Nodc,  on  the  other  hand,  will  handle  many  of  the  low  level 
details  necessary  to  maintain  consistency  in  the  node  data  base.  Thus,  it  can  be  used  more 
effectively  by  the  programmers  of  ENCORE  tools.  The  optional  parameter  ‘Label,’  indi¬ 
cates  a  name  under  which  the  node  is  to  be  stored  in  the  node  data  base. 

3J1.2  Functions  for  Building  Primitive  Nodes 

The  package  Primitive_Node_Creation  provides  a  number  of  functions  for  building  prim¬ 
itive,  or  scalar,  nodes,  such  as  integers,  strings,  booleans,  etc.  Many  of  these  functions  are 
overloaded,  in  order  to  allow  different  types  of  parameters.  Consider,  for  example,  the 
function  Make.Integer.  There  are  three  different  versions 

function  Make_Integer(X ;  Integer)  return  AdaTran.Node; 
function  Make_Integer(X  :  String)  return  AdaTran_Node; 
function  Make_Integer(X  :  A_String)  return  Adalfan.Node; 

The  first  Make.Integer  functicm  allows  one  to  build  a  node  from  an  ijctual  integer.  The 
second  allows  one  to  build  a  node  frcrni  a  string  that  represents  an  inuger.  Finally,  the  third 
allows  one  to  build  a  node  firom  a  pointer  to  a  string. 

The  other  creation  functions  for  primitive  nodes  are  Make.Boolean,  Make.Character, 
Make.Float,  Make_String,  and  Make.Symbol. 
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There  is  also  one  function  for  building  up  sequences  of  symbol  nodes.  This  is  the  function 
defined  by 

function  Make_Seq_Of_Symbol(S  :  SeqjC)f_Symbol)  return  Seq_Of_AdaTran_Node; 

This  function  accepts  a  sequence  of  actual  symbols  and  builds  a  sequence  of  nodes,  each 
of  type  k_Symbol. 

Functions  for  Building  Structured  Nodes 

The  functions  for  building  structured  nodes  allow  the  user  to  build  a  complete  node  with 
all  the  attributes  in  place.  Some  examples  are 

function  Make_Abort(p_Tasks :  Seq_Of_AdaTran_Node; 

Node.Label :  Symbol  :=  The_Symbol_Undcfincd) 

return  AdaTran_Node; 


function  Make_Func_Spec(p_Body :  AdaTran_Nodc; 

p_Context :  Scq_Of_AdaTran_Node; 
p.Designaton  AdaTran_Node; 
p_Parameters :  Seq_Of_AdaTran_Nodc; 
p_Retum_Typc :  AdaTran_Nodc; 

Node_Labcl :  Symbol  :=  Thc_Symbol_Undcfined) 

return  AdaTran_Node; 


function  Make_Others(Node_Label ;  Symbol  :=  The_Symbol_Undcfined) 

return  AdaTran_Nodc;. 

The  names  of  parameters  that  correspond  to  attribute  values  are  all  prefixed  with  ‘p_.’ 
This  avoids  any  clashes  with  Ada  reserved  words.  For  example,  several  classes  of  node 
contain  an  attribute  called  ’type.’  This  would  cause  a  conflict  with  the  reserved  word 
‘type’  in  Ada,  unless  we  altered  the  name  somehow. 

3  J  The  Package  Primitive_A<lalVan_Interface 

The  package  Primitive_AdaTran_Interface  provides  routines  for  accessing  and  manipulat¬ 
ing  AdaTran.Nodes. 

3J.1  The  Function  Kind 
The  function  Kind,  defined  by 

function  Kind(x :  AdaTran.Node)  return  AdaTran_Node; 
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allows  the  user  to  query  a  node  as  to  its  class.  Quite  often  the  various  ENCORE  tools  will 
use  a  case-statement  based  on  the  result  of  Kind(x),  then  perform  different  operations 
depending  on  the  actual  kind  of  the  node. 

3J.2  Accessing  Primitive  Nodes 

Primitive  nodes  can’t  be  altered,  so  the  only  operation  available  is  to  retrieve  the  actual 
primitive  values  from  the  nodes.  For  example,  we  can  retrieve  the  integer  value  of  an  inte¬ 
ger  node.  The  actual  functions  are 

function  As_Boolean(N  :  AdaTran_Node)  return  Boolean; 
function  As_Character(N :  Ada'IYan_Node)  return  Character, 
function  As_Float(N  :  AdaTran_Nodc)  return  Float; 
function  As_Integcr(N  :  AdaTran_Node)  return  Integer, 
function  As_String(N ;  AdaTran_Node)  return  String; 
function  As_A_String(N :  AdaTran_Nodc)  return  A_String; 
function  As_Symbol(N  :  AdaTran_Nodc)  rettrni  Symbol; 

The  function  As_A_String  needs  some  additional  comments.  The  type  A.String  is  an 
access  type  whose  values  are  pointers  to  strings  (A_String  is  described  in  the  package 
Basic.Strings).  ^th  string  nodes,  it  is  important  to  be  able  to  view  the  string  value  of  a 
string  node  as  either  an  actual  string  or  as  a  pointer  to  a  string.  This  is  because  the  type 
String  in  Ada  is  an  unconstrained  array  type,  which  is  inconvenient  to  use  in  some  con¬ 
texts. 

Finally,  there  is  a  function  defined  by 

function  As_Seq_C)f_Symbol(S :  Seq_Of_AdaTran_Node) 

return  Seq_Of_AdaTran_Node; 

This  function  takes  a  sequence  of  AdaTran_Node(s),  all  presumed  to  be  of  type 
k.Symbol,  and  returns  a  sequence  of  Symbols.  As  such,  it  is  the  reverse  of  the  function 
Make_Seq_Of_Symbol,  defined  in  the  package  Primitive_Node_Creation. 

33.3  Accessing  Structure  Nodes 

For  each  attribute  name,  there  are  two  corresponding  functions,  a  *Get_’  function  and  a 
‘Sct_’  function.  The  Get  function  retrieves  the  f  ttribute  of  the  given  name,  while  the  Set 
function  assigns  a  value  to  the  attribute.  Two  examples  are 

Get_Type(N  :  AdaTran_Node)  return  AdaTran_Node; 

Seuiy^fN  :  AdaTran_Node;  To_Bc :  AdaTran_Node); 

and 

Get_Declarations(N  :  Adalhm.Nodc)  return  Seq_C)f_AdaTran_Node; 
Set_Declarations(N  :  AdaTran_Node;  To_Bc :  Seq_C)f_AdaTran_Node); 
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The  first  two  functions  provide  access  to  the  ‘type’  attribute  of  any  typed  node,  such  as  a 
var_decl,  const_dccl,  etc. 

The  last  two  functions  provide  access  to  the  ‘declarations’  attribute  for  any  node  corre¬ 
sponding  to  a  scope.  These  include  nodes  of  class  pkg_spec,  pkg_bdy,  block,  etc. 
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Appendix  C 


ADL  Description  of  the  Ada  Internal 
Representation 


-  ADL  Description  of  the  Ada  Internal  Representation 


module  AdaTran  is 

••  Primitive  Node  l^pes 

primitive  Boolean; 
primitive  Character; 
primitive  Float; 
primitive  Integer, 
primitive  String; 
primitive  Symbol; 

stub  Empty; 
stub  Undefined; 

-  Structured  Classes 

”  2,8  pragmas 

pragma  => 
designator :  Symbol, 

parameters :  seqof  EXP_OR_ASSOCIATION; 

EXP_OR_ASSCX3ATION  ::=  EXP  I  association; 

-  3.  declarations  and  types 

-  3.1  declarations 

DECL  pragma  I  use.elem  I 

MULTIPLE_DESIGNATORS_ITEM  I  REP  I  SINGLE_DESIGNATOR_ITEM; 

~  3.2  objects  and  named  numbers 

MULTIPLE_DESIGNATORS_nEM  ::=  num_dccl  I  var_dccl  I  const_decl; 
EXP_OR_EMPTY  ;:=  EXP  I  Empty; 

SUBTYPE_INDICATION  :=  constrained.reference  REFERENCE; 
num_decl  => 

designates  :  seq  of  Symbol, 
initial_value :  EXP_OR_EMPTY, 
refetencers  :  seq  of  named_ref  , 
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type 


:  SUBTYPE.INDICATION; 


var_decl  *> 

constraints  :  scq  of  CONSTRAINT, 
designators  :  seq  of  Symbol, 
initial_value :  E>6»_OR_EMPTY, 
referencers  :  seq  of  named_ref  , 
type  :  SUBTYPE.INDICATION; 

const_decl  => 

constraints  :  seq  of  CONSTRAINT, 
designators  :  seq  of  Symbol, 
initial.value ;  EM*_OR_EMPTY, 
referencers  :  seq  of  named_ref, 
type  :  SUBTYPE.INDICATION; 

->  33  types  and  subtypes 

”  33.1  type  declarations 

SINGLE_DESIGNAT0R_1THM  type_decl  I  subtype_decl; 

type_decl  => 
designator :  Symbol, 
info  :  TYPE.INFO, 
referencer :  direct_ref; 


-  33.2  subtype  declarations 

subtype_decl  => 

base.type  :  SUBTYPE.INDICATION, 
constraints  :  seq  of  CONSTRAINT, 
designator  :  Symbol, 
referencer  :direct_ref; 


••  3.4  derived  type  defintions 

TYPE_INFO  derived_type_info; 

derived_type_info  => 
base.type  :  SUBTYPE.INDICATION, 
constraints :  scq  of  CONSTRAINT, 
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“  3^  scalar  types 

TYPE_INFO  ;:=  enuiiierated_typc_info; 

enumcrated_typc_info  => 
values :  seq  of  enumeration_literal; 

enumeration.literal  => 
basc_type :  SUBTYPE_INDICATION, 
type  :  dircct_ref, 

value  :  SYMBOL_OR_C3iARACrER; 

SYMBOL_OR_CHARACTER  ::=  Symbol  I  Character, 

»  3^.4  integer  types 

TYPE_INFO  ::=  integer_type_info; 

integer_type_info  => 
range :  SIMPLE_RANGE; 

-  3.5.9  real  types 

TYPE.INFO  ::=  REAL_TYPE_INFO; 

REAL_TYPE_INFO  float_type_info; 
float_type_info  => 
digits :  EXP, 

range  :  SIMPLE_RANGE_OR_EMPTY; 

REAL_TYPE_INFO  ::=  fixed_type_info; 
fixed_type_info  => 
delta :  EXP, 

range :  SIMPLE_RANGE_OR_EMPTY; 
SIMPLE_RANGE_OR_EMPTY  ::=  SIMPLE_RANGE  I  Empty; 

-  3.6  array  types 
TYPE_INFO  ::=  array_type_info; 
array_type_info  => 

base_type ;  SUBTYPE.INDICATION, 
ranges  :  seq  of  RANGE; 

RANGE  disciete.range; 
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SIMPLE_RANGE  ::=  discrete_range; 

discrete_range  => 

basc.typc :  SUBTYPE.INDICATION, 
max  :  EXP, 

min  :  EXP; 

RANGE  ;;=  indexjconstraint; 

index_constraint  => 
base_type :  SlJBTYPE_INDICATION, 
max  :  EXP. 

min  :  EXP; 

RANGE  ::=  univcrsal_index_range; 

univcrsal_index_range  => 
basc_typc :  SUBTYPE.INDICATION, 
max  :  EXP, 

min  :  EXP; 

RANGE  univcrsal_intcgcr_range; 

universal_integer_rangc  => 
basc.typc :  SUBTYPE.INDICATION, 
max  :  EXP, 

min  :  EXP; 

RANGE  ::=  REFERENCE; 

-  3.7  recoid  types 

TYPE_INFO  ::=  record_type_info; 

record_type_info  => 
components  :  seq  of  component.decl, 
discriminant :  seq  of  component.decl; 

MULTIPLE_DESIGNATORS_ITEM  ::=  component_decl; 

COMPONENT  component.decl  I  pragma; 

component.decl  => 
constraints  :  seq  of  CONSTRAINT, 
designattvs  :  seq  of  Symbol, 
initial_value :  E?Q*_OR_EMPTY, 
referencers  :  seq  of  named.ref, 
type  :  SUBTYPE.INDICATION; 
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COMPONENT  null_componcnt; 

null_component  => ; 

COMPONENT  variaxit_part; 
variant^art  => 
discriminator :  named.ief, 
variants  :  seq  of  variant; 


variant  => 

choices  :  seq  of  CHOICE_OR_OTHERS, 
components :  seq  of  COMPONENT; 

CHOICE_OR_OTHERS  :;=  EXP  I  GENERAL_DISCRETE_RANGE  I  others; 


others  =>; 

>-  3^  access  types 

TYPE_INFO  ::=  pointer_type_info; 

pointer_type_info  => 
base.type :  SUBTYPEJNDICATION; 

-  3^.1  Incomplete  l^'pe  Declarations 

TYPE.INFO  ::=  TYPE.STUB; 

TYPE_STUB  ::=  incomplete_type_info; 

incomplete_type_info  => 
completion  :  DIRECT_REF_OR_EMPTY, 
discriminant :  seq  of  component.decl; 

TYPE_STUB  ::=  private_type_info; 

private_type_info  => 

completion  :  DIRECT_REF_OR_EMPTY, 
discriminant :  seq  of  component.decl; 

TYPE_STUB  ::=  limited_private_type_info; 

limitcd_private_type_info  => 
cmnpletion  :  DIRECT_REF_OR_EMPTY, 
discriminant :  seq  of  component.decl; 
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TYPE_INFO  ::=  type_completion_info; 
typc_completion_info  => 
info :  TYPE.INFO, 
stub :  DIRECT_REF_OR_EMPTY; 

DIRECr_REF_OR_EMPTY  ::=  direct_ref  I  Empty; 

-  3.9  declarative  parts 

~  4  names  and  expressions 

-  4.1  names 

"  4.1.1  indexed  components 

REFERENCE  indexed_ref; 
indexcd_ref  => 
indices  :  seq  of  EXP, 
representations  ;  seq  of  REP, 
target  :  EXP; 

-  4.1.2  slices 


slice  => 

range  :  GENERAL_DISCRETE_RANGE, 
target :  EXP; 

GENERAL_DISCRETE_RANGE  constrained_reference  I  REFERENCE  I  SIM- 
PLE.RANGE; 

-  4.13  selected  components 

REFERENCE  ;:=  component_ref; 

ccMnponent_ref  => 
component  :  EXP, 
representations  :  seq  of  REP, 
target  :  EXP; 

-  4.1.4  attributes 

SIMPLE_RANGE  ::=  attribute; 
attribute  => 
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designate ;  Symbol, 
exp  ;  EXP; 

SIMPLE_RANGE  ::=  attribute.call; 

attribute_call  => 
attribute :  attribute, 
exp  :  EXP; 

"  4.2  literals 

EXP  ;:=  LITERAL; 

LITERAL  :=  Boolean  I  Integer  I  Float  I  Symbol  I  Character  I  String; 

-  4  J  aggregates 

LITERAL  ::=  aggregate; 
aggregate  => 

components  :  seq  of  ACnJAL_COMPONENT; 

ACTUAL_COMPONENT  ::=  association  I  others_part  I  EXP; 

others_part  => 
exp :  EXP; 

-  4.4  expressions 

EXP  ::=  REFERENCE; 

-  4.4.B  relations 

EXP  membership; 

membership  => 
exp :  EXP, 

op  :  MEMBERSHIP.OP, 
set :  discrete_range; 

MEMBERSHIP_OP  ::=  in_op  I  not_in; 


in_op  => ; 
not_in  => ; 

”  4.5  operators  and  expression  evaluation 
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-  See  Function  Calls 


»  4.6  type  conversions 


EXP::=QUAL_CX)NV; 

QUAL_CX)NV  ::=  conversion; 

conversion  => 
exp  :EXP, 

type :  SUBTYPE.INDICATION; 

-  4.7  qualified  expressions 

QUAL_CX)NV  :;=  qualified.expression; 

qualified.expression  => 
exp  :  EXP, 

type :  SUBTYPEJNDICATION; 

-  4.8  allocators 

EXP  ::=  ALLOCATOR; 

ALLOCATOR  ::=  uninidalized.allocator, 

uninitialized.allocator  => 
constraints  :  seq  of  CONSTRAINT, 
object_typc :  SUBTYPE_INDICATION, 
type  :  SUBTYPE.INDICATION; 

ALLOCATOR  ::=  initialized.allocator, 

initialized_allocator  => 
constraints  :  seq  of  CONSTRAINT, 
expr  ;  qualified.expression, 

type  :  SUBTYPE.INDICATION; 

EXP  ::=  nulLexp; 

nulLexp  => ; 

”  5  Statements 

STMT  pragma; 

STMT  ::=  labeled_stmt; 
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labeled_stmt  => 
labels  :  seq  of  Symbol, 
refeiencers  :  seq  of  named_ief, 
statement  :  STMT; 

STMT  ::=  nulLstmt; 


null_stmt  => ; 

~  5^  assignment  statement 

STMT  ::=  assignment.stmt; 

assignment_stmt  -> 
target :  REFERENCE, 
source :  EXP; 

••  S3  if  statements 

STMT  ::=  if_stmt; 
if_stmt  => 

then_pan  :  then.clause, 
else_parts :  ELSES_OR_EMPTY; 

then.clause  => 
cond  :  EXP, 
statements :  seq  of  STMT; 

ELSES_OR_EMPTY  ::=  elses_part  I  Empty; 

elses_part  => 

else_part :  ELSE_CLAUSE_OR_EMPTY, 
elsifs  :  seq  of  elsif.clause; 

elsif_clause  => 
cond  :  EXP, 
statements  :  seq  of  STMT; 

ELSE_CLAUSE_OR_EMPTY  ::=  else_clause  I  Empty; 

else_clause  => 
statements  :  seq  of  STMT; 

--  5.4  case  statements 

STMT  ::=  case_stmt; 
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case.stmt  => 
alternatives :  seq  of  altem, 
case_exp  :  EXP; 

altem  => 

choices  ;  seq  of  CHOICE_OR_OTHERS, 
statements :  seq  of  STMT; 

-  5^  loop  statements 

STMT  ::=  loop_stmt; 

loop_stmt  => 
iterator  ;  ITERATOR, 
label  :  Symbol, 
refcrencer ;  direct_ref, 
statements  :  seq  of  STMT; 

ITERATOR  ::=  whilejter, 

whilejter  => 
condition ;  EXP; 

ITERATOR  ::=  for_iter, 

for_iter  => 

init_and_end :  GENERAL_DISCRETE_RANGE, 
refcrencers  :  seq  of  namcd_rcf, 
variable  ;  Symbol; 

ITERATOR  ::=  reversejter, 

rcvcrsejter  => 

init_and_end :  GENERAL_DISCRETE_RANGE, 
refcrencers  ;  seq  of  named_ref, 
variable  :  Symbol; 

-  5.6  block  statements 

STMT  ::=  block; 
block  => 

declarations  :seqofDECL, 
exception_handler :  seq  of  altem, 
label  :  Symbol, 
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refeiencer 

statements 


:  direct_ref, 

:  seq  of  STMT, 


~  5.7  exit^statements 

STMT  ::=  exit_stmt; 
exit_stmt  => 

level  :  REFERENCE_OR_EMPTY, 
when_condition :  EXP_OR_EMPTY; 

REFERENCE_OR_EMPTY  ::=  REFERENCE  i  Empty; 

-  5.8  return  statements 

STMT  ::=retum_stmt; 
retum_stmt  => 
value :  EXP_OR_EMPTY; 

-  5.9  goto  statements 

STMT  goto.stmt; 
goto_stmt  => 
target :  REFERENCE; 

~  6  subprograms 

-  6.1  subprogram  declarations 

SINGLE_DESIGNATOR_ITEM  ::=  func_spec; 
func_spcc  => 

body  :  DIRECT_REF_OR_EMPTY, 
context  :  seq  of  CONTEXT_ELEM, 
designator  :  Symbol, 
parameters  :  seq  of  FORMAL, 
rcfcrencer  :direct_ref, 
retum_type :  direct_ref; 

SINGLE_DESIGNATOR_l  I'EM  ::=  proc_spcc; 


proc_spcc  => 

body  :  DIRECT_REF_OR_EMPTY, 
context  :  seq  of  CONTEXT_ELEM, 
designator :  Symbol, 
parameters :  seq  of  FORMAL, 
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leferencer :  direct_ref; 


-  6.1.C  formal  part 

FORMAL  ::=  in_formal  I  out_fonnal  I  inout.formal; 


in_fonnal  => 

designators  :  seq  of  Symbol, 
iiutial_value :  EXP_OR_EMPTY, 
refeiencers  :  seq  of  named.ref, 
type  :  SUBTYPE.INDICATION; 

FORMAL  ::=  out_fonnal; 
out.formal  => 
designators  :  seq  of  Symbol, 
referencers :  seq  of  named_ref, 
type  :  SUBTYPE_INDICATION; 

FORMAL  ::=  inout_formal; 

GENERIC_PARAMETER  ;:=  inout_formal; 
inout_fonnal  => 
designators :  seq  of  Symbol, 
referencers :  seq  of  named_ref, 
type  ;  SUBTYPE.INDICATION; 

-  6  J  subprogram  bodies 

SINGLE_DESIGNATOR_ITEM  ::=  func_bdy; 
func_bdy  => 

context  :  seq  of  CONTEXT_ELEM, 

declarations  :  seq  of  DECL, 
designator  :  Symbol, 
exception.handler :  seq  of  altem, 
parameters  :  seq  of  FORMAL, 

referencer  :  dircct_ref, 

retum_type  ;  direct_ref, 

spec  :  DIRECT_REF_OR_EMPTY, 

statements  :  seq  of  STMT; 

SINGLE_DESIGNATOR_ITEM  ::=  proc.bdy; 

proc_bdy  => 

context  ;  seq  of  CONTEXT_ELEM, 

declarations  :  seq  of  DECL, 
designator  :  Symbol, 
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exception_handler :  seq  of  altem, 
parameters  :  seq  of  FORMAL, 
referencer  :  dir^_ref, 
spec  :  DIRECT_REF_OR_EMPTY, 

statements  :  seq  of  STMT, 

~  6.4  subprogram  calls 

STMT  ::=  proc_cail; 


proc_call=> 

parameters :  seq  of  EXP_OR_ASSOCIATION, 
proc  :  REFERENCE; 

EXP  ::=  function_call; 

function.call  => 
function  ;  REFERENCE, 
parameters :  seq  of  EXP_OR_ASSOCIAnON; 


••  7  packages 

••  7.1  package  structure 

SINGLE.DESIGNATORJTEM  ::=pkg_spec; 
pkg_spec  => 

body  :  DIRECT_REF_OR_EMPTY, 

context  ;  seq  of  CONTEXT_ELEM, 

declarations  :seqofDECL, 
designator  :  Symbol, 

private.declarations :  seqof  DECL, 
referencer  :  direct_ref; 

SINGLE_DESIGNATOR_ITEM  ::=pkg_bdy; 

pkg_bdy  => 

context  :  seq  of  CONTEXT_ELEM, 

declarations  :  seq  of  DECL, 

designator  :  Symbol, 

exception.handler :  seq  of  altem, 
referencer  :  direct_ref, 

spec  :  DIRECr_REF_OR_EMPTY, 

statements  :  seq  of  STMT; 
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>•  7.4  private  type  and  deferred  constant  declarations 

MULTIPLE_DES1GNAT0RS_ITEM  ::=  deferred_cc»ist_decl; 

defened_const_decl  => 
decl  :  const.decl, 
designators :  seq  of  Symbol, 
referencers :  seq  of  named.ref, 
type  :  SUBTYPE_INDICATION; 

-  8  visibility  rules 

-  8.4  use  clauses 

DECL  use_elem; 

CONTEXT_ELEM  ::=  use_elem; 

use_elem  => 
items  :  seq  of  Symbol; 

»  8.5  renaming  declarations 

MUUnPLE_DESIGNATORS_ITEM  exccption_ienamc; 

exception_rename  => 
designators :  seq  of  Symbol, 
item  :  REFERENCE; 

SINGLE_DESIGNAT0R_1TEM  ;;=  func_renamc; 

func_rename  => 
designator  :  Symbol, 
item  :  REreRENCE, 
parameters  :  seq  of  FORMAL, 
rcfcrencer  :direct_ref, 
retum_type :  direct_ref; 

MULTIPLE_DESIGNATORS_ITEM  :;=  object_rcname; 

object_rename  => 
designators  :  seq  of  Symbol, 

item  :  REFERENCE; 

SINGLE_DESIGNATOR_ITEM  ::=  pk^iename; 

pkg_rcname  => 
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designator ;  Symbol, 
item  :  REFERENCE, 
lefeiencer :  direct_ref; 

SINGLE_DESIGNATOR_ITEM  ::=  proc_rename; 

proc_rename  »> 
designator :  Symbol, 
item  :  REFERENCE, 
parameters :  seq  of  FORMAL, 
referencer :  dir»ct_rcf; 

»  9  tasks 

-  9.1  task  specifications  and  task  bodies 

SINGLE_DESIGNATOR_ITEM  ::=  task_type_decl; 

task_type_decl  => 
designator :  Symbol, 
referencer :  direct_ref, 
spec  :  DIRECT_REF_0R_EMPTY; 

SINGLE.DESIGNATOR.ITEM  ::=  task_spcc; 
TYPE_INFO  task_spcc; 

task.spec  => 

body  :  DIRECr_REF_OR_EMPTY, 
context  :  seq  of  CONTEXT_ELEM, 
declarations  :  seq  of  DECL, 
designator  :  Symbol, 
referencer  :dircct_ref; 


SINGLE_DES1GNAT0R_ITEM  ::=  task.bdy; 


task_bdy  => 

cmitext  :  seq  of  CONTEXT_ELEM, 
declarations  :  seq  of  DECL, 
designator  :  Symbol, 
excepdon.handler :  seq  of  altem, 
referencer  ;  direct_ref, 
spec  :  DIRECT_REF_OR_EMPTY, 

statements  :  seq  of  STMT, 


-  9.5  entries,  entry  calls  and  accept  statements 


SINGLE_DESIGNATOR_ITEM  cntiy; 


entry  => 

designator :  Symbol, 
parameters :  seq  of  FORMAL, 
range  :  RANGE_OR_EMPTY, 
referencer :  dircctjref; 

RANGE_OR_EMPTY  ::=  RANGE  I  Empty; 

entry_call  => 
entry  :  direct_ref, 
index  :  EXP_OR_EMPTY, 
parameters  :  seq  of  EXP_OR_ASSOCIATION; 

STMT  ::=  accept; 
accept  => 

entry  :  REFERENCE, 
index  :  EXP_OR_EMPTY, 
parameters  :  seq  of  FORMAL, 
referencer :  direct_ref, 
statements  :  seq  of  STMT; 

-  9.6  delay  statements,  duration  and  time 

delay  => 
exp :  EXP; 

"  9.7  select  statements 

“  9.7.1  selective  waits 

select  => 

select.clauses  :  seq  of  SELECT_CLAUSE_ELEM, 
statements  :  seq  of  STMT; 

SELECT_CLAUSE_ELEM  ::=  pragma  I  select_clause; 

select.clause  => 
cond  ;  EXP, 
statements ;  seq  of  STMT; 

STMT  ::=  terminate; 

terminate  => ; 
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~  9.7.2  conditional  entry  calls 

STMT  ::=  ENTRY_STMT; 
ENTRY_STMT  ::=  cond_cntry; 
cond_cntry  => 

failure.statements :  seq  of  STMT, 
success.statements :  seq  of  STMT, 

-  9.7.3  timed  entry  calls 

ENTRY_STMT  ::=  timed_entry; 
tiiiicd_entry  => 

failure.statements  :  seq  of  STMT, 
success_statements :  seq  of  STMT; 

-  9.10  abort  statements 

STMT  ::=  abort; 


abort  => 

tasks :  seq  of  REFERENCE; 

"  10  program  structure  and  compilation  issues 
- 10.1  compilation  units  >  library  units 

UNTT.DECL  ::=  GENERIC.INSTANTIATION  ACTUAL.SPEC  ACTUAL.BODY; 

ACrUAL.SPEC  ::= 
func_spec  I 
func.instantiation  I 
generic_func_spec  I 
generic_pkg_spec  I 
generic_proc_spcc  I 
pkg_spec  I 
pkg_instantiation  I 
pkg_spec  I 
proc_spec  I 
procjnstantiation  I 
task_spec; 

ACTUAL.BODY  ::= 
func_bdy  I 
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fuiic_iiistantiation_bdy  I 
generic_func_bdy  I 
gcncric_pkg_bdy  I 
gcncric_proc_bdy  I 
pkg_bdy I 

pkg_instantiation_bdy  I 
proc_bdy  I 

proc_instantiation_bdy  I 
task_bdy; 

(X)NTEXT_ELEM  with_elein; 
-CONTEXT_ELEM  ::=  usc.clcm; 


with_clem  => 
items :  seq  of  Symbol; 

» 10^  subunits  of  compilation  units 

SINGLE_DESIGNATOR_ITEM  ::=  stub; 
stub  => 

designator :  Symbol, 

referencer :  direct_ref, 

spec  :  DIRECT_REF_OR_EMPTY, 

subunit  :  DIRECT_REF_OR_EMPTY; 

SINGLE_DESIGNATOR_ITEM  ::=  subunit; 

subunit  => 

body  :  DIRECT_REF_OR_EMPTY, 

designator ;  Symbol, 

referencer :  duwt.ref, 

spec  :  DIRECT_REF_OR_EMPTY, 

stub  :  DIRECT_REF_OR_EMPTY; 

“  11  exceptions 

- 11.1  exception  declarations 

MULTIPLE_DESIGNATORS_ITEM  ::=  cxception_decl; 

cxception_decl  => 
designators  :  seq  of  Symbol, 
referencers :  seq  of  named_ref; 
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- 11.2  exception  handlers 


-  lU  raise  statements 

STMT  ::=raise_stmt; 

raise_stmt  => 
exception :  named.ref; 

- 12  generic  program  units 

GENERIC_IJNIT  :=  generic_func_spec  I  generic_proc_spec  I 
generic_func_bdy  I  generic_proc_bdy  I 
generic_pkg_spec; 

GENERIC_PARAMETER  ::=  generic_type_parain  I 

in_fomml  I 
inout.fonnal  I 

GENERIC_SUBPROGRAM_PARAM; 

SINGLE_DESIGNATOR_rTEM  generic_type_parain; 

generic_type_parain  => 
designator ;  Symbol, 
info  :  GENERIC_TYPE_INFO, 
referencer ;  direct_rcf; 

GENERIC_TYPE_INFO  ::=  generic_<iiscrcte_info  I  generic_integer_info  I 

generic_float_info  I  generic_fixed_info  I 
TYPE.INFO; 


generic_discrete_info  => ; 
generic_integer_info  => ; 
generic_float_info  => ; 
generic_fixed_info  => ; 

GENERIC_SUBPROGRAM_PARAM  ::=  generic_func_param  I  generic_proc_param; 
generic_func_param  => 

default_subprogram :  SYMBOL_BOX_SUBPRCX3RAM_OR_EMPTY, 
designator  ;  Symbol, 

parameters  :  seq  of  FORMAL, 
referencer  :  direct_rcf, 
rctum_type  ;  diiect_ref; 
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generic_proc_param  => 

dcfault_subprogram :  SYMBOL_BOX_SUBPROGRAM_OR_EMPTY, 
designator  :  Symbol, 

parameters  :  seq  of  FORMAL, 

refeiencer  :  direct_ref; 

SYMBOL_BOX_SUBPROGRAM_OR_EMPTY  box.subprogram  I  Empty  I  Sym¬ 
bol; 

box.subprogram  => ; 

SINGLE_DESIGNATOR_ITEM  ::=  generic_func_spec; 

generic_func_spec  => 
body  ;  DIRECT_REF_OR_EMPTY. 
context  ;  seq  of  CX)NTEXT_ELEM, 
designator  :  Symbol, 

g_parameters  :  seq  of  GENERIC_PARAMETER, 
parameters  :  seq  of  FORMAL, 
referencer  :  direct_ref, 
rctum_type  :  direct_rcf; 

SINGLE_DESIGNATOR_ITEM  ::=  gcneric_proc_spec; 

generic_proc_spec  *> 
body  ;  DIRECT_REF_OR_EMPTY, 
context  :  seq  of  CX)NTEXT_ELEM, 
designator  :  Symbol, 

g_parameters  :  seq  of  GENERIC_PARAMETER, 
parameters  :  seq  of  FORMAL, 
referencer  :  direct_rcf; 


SINGLE_DES1GNAT0R_I  I'EM  generic_pkg_spec; 


generic_pkg_spec  => 

body  :  DIRECT_REF_OR_EMPTY, 

context  :  seq  of  CX)NTEXT_ELEM, 

declarations  ;  seq  of  DECL, 

designator  ;  Symbol, 

g  parameters  :  seq  of  GENERIC_PARAMETER, 
private.declarations  :  seq  of  DECL, 
referencer  :  direct_rcf; 


SINGLE_DESIGNATOR_ITEM  :;=  gencric_func_bdy; 
generic_func_bdy  => 
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context  :  seq  of  CONTEXT_ELEM, 

declarations  :  seq  of  DECL, 

designator  :  Symbol, 

exception_hnndler :  seq  of  altem, 

g  parameters  :  seq  of  GENERIC_PARAMETER, 

parameters  :  seq  of  FORMAL, 

refeiencer  :  direct_ref, 

retum_type  :  direct_ref, 

spec  :  DIRECT_REF_OR_EMPTY, 

statements  :  seq  of  STMT; 

SINGLE_DESIGNATOR_ITEM  ::=  generic_proc_bdy; 

generic_proc_bdy  => 
context  :  seq  of  CONTEXT_ELEM, 

declarations  :  seq  of  DECL, 
designator  :  Symbol, 
exception_handler :  seq  of  altem, 
g_parameters  :  seq  of  GENERIC_PARAMETER, 
parameters  :  seq  of  FORMAL, 
referencer  :  direct_ref, 
spec  :  DIRECT_REF_OR_EMPTY, 

statements  :  seq  of  STMT; 

SINGLE.DESIGNATOR.ITEM  ::=  generic_pkg_bdy; 

generic_pkg_bdy  => 

context  :  seq  of  CONTEXT_ELEM, 

declarations  :  seq  of  DECL, 
designator  :  Symbol, 
exception_handler ;  seq  of  altem, 
referencer  :  direct_ref, 
spec  :  DIRECT_REF_OR_EMPTY, 

statements  :  seq  of  STMT; 

- 123  generic  instantiation 

GENERIC_ACTU  AL_PARAMETER  :=  EXP;  -  for  now 

SINGLE_DESIGNAT0R_1TEM  ::=  func_instantiation; 

GENERIC_INSTANTIATION  ::=  funcjnstandation; 

funcjnstantiation  => 
body  :  DIRECT_REF_OR_EMPTY, 
context  ;  seq  of  CONTEXT_ELEM, 
designator  :  Symbol, 
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g_actuals  :  seq  of  GENERIC_ACTUAL_PARAMETER, 

instance_of :  REFERENCE, 

parameters  :  seq  of  FORMAL, 

referencer  :  direct_ref, 

retum_type :  direct_ref, 

spec  :  DIRECT_REF_OR_EMPTY; 

SINGLE_DESIGNATOR_ITEM  ::=  proc.instandation; 

GENERIC_INSTANTIATION  ::=  proc.instantiation; 

proc.instantiation  => 
body  :  DIRECT_REF_OR_EMPTY, 
context  ;  seq  of  CONTEXT_ELEM, 
designator  ;  Symbol, 

g_actuals  :  seq  of  GENERIC_ACTUAL_PARAMETER, 

instance_of :  REFERENCE, 

parameters  :  seq  of  FORMAL, 

referencer  :  direct_ref, 

spec  :  DIRECT_REF_OR_EMPTY; 

SINGLE_DESIGNATOR_ITEM  ::=  pkg_instantiation; 

GENERIC_INSTANTIATION  pkg_instantiation; 

pkg^instandation  => 
body  :  DIRECr_REF_OR_EMPTY, 
context  :  seq  of  CONTEXT_ELEM, 
designator  :  Symbol, 

g_actuals  :  seq  of  GENERIC_ACTUAL_PARAMETER, 

instance_of :  REFERENCE, 

referencer  :  dircct_ref, 

spec  :  DIRECT_REF_OR_EMPTY; 

SINGLE_DESIGNATOR_l  I'EM  ::=  func_instandation_bdy; 

GENERIC_D*JSTANTIATION  ::=  func_instandadon_bdy; 

func_instandadon_bdy  => 
context  :  seq  of  CONTEXT_ELEM, 
declaradons  :  seq  of  DECL, 
designator  :  Symbol, 
excepdon_handler :  seq  of  altem, 

g_actuals  :  seq  of  GENERIC_ACnJAL_PARAMETER, 

instance_of  :  REFERENCE, 

referencer  :  direct_ref, 

spec  :  DIRECT_REF_OR_EMPTY, 

statements  :  seq  of  STMT; 

SINGLE_DESIGNATOR_ITEM  ::=  proc_instandadon_bdy; 

GENERIC_INSTANTIATION  ::=  proc_instandadon_bdy; 
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proc_instantiation_bdy  => 
context  :  seq  of  CONTEXT_ELEM, 
declarations  :  seq  of  DECL, 

designator  ;  Symbol, 

exception_handler :  seq  of  altem, 

g_actuals  :  seq  of  GENERIC_ACrUAL_PARAMETER, 

instance_of  :  REFERENCE, 

referencer  :  direct_ref, 

spec  :  DIRECT_REF_OR_EMPTY, 

statements  :  seq  of  STMT; 

SINGLE_DESIGNATOR_ITEM  ;;=  pkg_instantiation_bdy; 

GENERIC_INSTANTIATION  ::=  pkg_instantiation_bdy; 

pkg_instantiation_bdy  => 
context  :  seq  of  CONTEXT_ELEM, 
declaradons  ;  seq  of  DECL, 
designator  :  Symbol, 
exception_handler :  seq  of  altem, 

g_actuals  :  seq  of  GENERIC. ACTUAL_PARAMETER, 

instance.of  :  REFERENCE, 

referencer  :  direct.ref, 

spec  :  DIRECT_REF_OR_EMPTY, 

statements  :  seq  of  STMT; 

-  13  representation  clauses  and  implementation  dependent  features 

"  13.1  representation  clauses 

REP  ::=  record.rep  I  EXP.REP; 

type.attribute  => 
designator  :  Symbol, 
representations  :  seq  of  REP, 
type  ;  direct.rcf; 

(ADL  EXP.REP  =>  exp  EXP) 

(ADL  EXP.REP  :=  address.rep  length.clause  enumeration.rep)-- 13.3 

- 13.2  length  clauses 

EXP.REP  ::=  length.clause; 

length.clause  => 

exp  :  EXP,  -  exp  is  a  simple  expression 


Appendix  C 


May  1992 


23 


target :  REFERENCE_OR_TYPE_ATTRIBUTE; 

"  133  enumeration  representation  clauses 

EXP_REP  enumeration.rep; 
enumeration.Tep  => 
exp  :EXP,  -  exp  is  an  aggregate 
target :  REFERENCE_OR_TYPE_ATTRffiUTE; 

-  13.4  record  representation  clauses 

ALIGNMENT_OR_EMPTY  ::=  alignnaent !  Empty; 
alignment  => 

at_mod  :  EXP_OR_EMPTY, 
pragmas  :  seq  of  pragma; 

REP  ::=  record_rep; 
record_rep  => 

alignment  :  ALIGNMENT_OR_EMPTY, 
component_reps  :  seq  of  CXI)MPONENT_REP_ELEMENX 
target  ;  REFERENCE_OR_TYPE_ATTRIBlJTE; 

COMPONENT_REP_ELEMENT  ::=  component_rep  I  pragma; 

component_rep  => 
at_exp  :  E^, 
designator :  Symbol, 
range  :  RANGE; 

"  13.5  address  clauses 

EXP_REP  ::=  address_rep; 
address_rep  => 
exp  :  EJQ*, 

target :  REFERENCE_OR_TYPE_ATTRIBUTE; 

REFERENCE_OR_TYPE_ATTRIBUTE  ;;=  REFERENCE  I  type_attribute; 

type_attribute  => 
designator  :  Symbol, 
representations  :  seq  of  REP, 
type  :  direct_ref; 

"  13.8  machine  code  insertions 

machine_code  => 
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exp  :EXP, 

type :  REFERENCE; 

"  14  input-output 

-  X.1  Constraints 

CONSTRAINT  ::=  RANGE_CONSTRAINT  I  airay.constraint  I  Empty; 
RANGE_CONSTRAINT  ::=  EXP  I  RANGE; 

array.constraint  => 

element.constraints :  seq  of  CONSTRAINT, 
range_constraints  :  seq  of  RANGE; 

—  X.l  References 

REFERENCE  ::=  direct_ref  named_ref  indexed_rcf 
component_ref  object_ref  pointer_dereO 

REFERENCE  direct_ref; 

direct_ref  => 

representations ;  seq  of  REP, 

target  :  DECL_OR_STMT;  -  points  to  single  decls 

DECL_OR_STMT  :;=  DECL I  STMT; 

REFERENCE  ::=  object_ref; 
object_ref  => 

representations  :  seq  of  REP, 
target  :  EXP; 

REFERENCE  :;=  named_ref; 

named_ref  => 
designator  :  Symbol, 
representations  :  seq  of  REP, 
target  :  REFERENCE; 

REFERENCE  pointer_deref; 

pointer_deref  =>  --  the  ".all"  construct 
representations  :  seq  of  REP, 
target  :  REFERENCE; 
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EXP_OR_ASSOCIATION  ::=  association; 
ACTUAL_CX3MPONENT  ::=  association; 
association  => 
names  :  seq  of  EXP, 
value :  EXP; 

GENERAL_DISCRETE_RANGE  ::=  constrained.reference; 
SUBTYPE_INDICATION  ::=  constrained.reference; 

constrained.ieference  => 
constraint :  CDNSTRAINT, 
target  :  REFERENCE; 

unconstrained  => 

base_type :  SUBTYPE_INDICATION; 
end  module; 
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Appendix  D 

Introduction  to  ENCORE  Symbol  Table 


Introduction  to  the  ENCORE  Symbol  Table 
1.  The  Purpose  of  the  ENCORE  Symbol  Ihble 

The  purpose  of  the  ENCXDRE  Symbol  Table  is  to  allow  the  various  tools  in  ENCORE  to 
access  definitions  in  Ada  programs  within  the  context  of  particular  scopes. 

Some  goals  in  the  symbol  table  design  were; 

1.  The  symbol  table  should  be  incrementally  updatable.  One  should  be  able  to  add, 
remove,  or  replace  symbol  table  entries  at  any  time,  not  just  when  the  program  is  being 
read  in  initially. 

2.  From  any  point  in  any  scope  of  the  program,  the  symbol  table  should  appear  logically 
the  same  as  if  one  were  processing  the  Ada  code  at  that  point  in  the  program. 

3.  Any  tool  that  works  on  the  IRep  should  be  able  to  access  the  symbol  table. 

4.  More  than  one  tool  should  be  able  to  access  the  symbol  table  simultaneously,  even 
within  multiple  scopes. 

1.1  Basic  Definitions 

Symbol  tables  are  used  to  store  information  that  can  be  referenced  from  more  than  one 
point  in  a  program.  Each  item  of  information  in  a  symbol  table  consists  of  two  parts,  a 
’key,’  which  gives  a  name  to  the  item,  and  a  ’value,’  which  gives  the  actual  information. 
Ad^ng  the  item  with  key  ’k’  and  value  *v’  to  a  symbol  table  is  called  storing  the  value  ‘v’ 
under  the  key  ’k.’ 

Some  of  symbol  table  terminology  has  been  used  with  slightly  different  meanings  in  the 
current  literature.  This  report  will  adopt  the  following  meanings  for  the  common  symbol 
table  terms. 

1.  The  phrase  ’the  symbol  table’  means  the  entire  symbol  table  strucnue  associated  with  a 
particular  Ada  program. 

2.  The  non-specific  term  ’symbol  table’  will  denote  a  table  of  keyA'alue  pairs.  The  keys 
will  correspond  to  identifiers  or  characters  in  Ada,  while  the  values  will  correspond  to 
definitions  in  Ada.  For  flexibility  in  naodifying  Ada  programs,  the  values  will  be  refer¬ 
ences  (nodes  of  type  k_DIRECT_REF  or  k_NAMED_REF)  rather  than  actual  defini¬ 
tions. 

3.  The  term  ’scope’  will  mean  a  symbol  table  associated  with  a  segment  of  a  particular 
Ada  program  unit.  Thus,  a  scope  could  hold  information  about  a  specification,  a  private 
part,  or  a  body. 

4.  A  ’search’  is  an  object  that  is  used  for  accessing  symbol  tables.  A  search  object 
includes  all  the  local  and  nesting  information  necessary  for  searching  through  the  sym¬ 
bol  table  for  an  Ada  program. 

5.  The  ’base  table’  of  a  search  object  indicates  the  scope  in  which  searching  will  start 
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6.  Since  there  can  be  several  entries  witfi  the  same  key  in  the  symbol  table  for  an  Ada  pro¬ 
gram,  it  is  necessary  to  keep  track  of  which  entries  have  been  found  and  which  are  left 
to  search.  The  ‘search  cursor*  keeps  track  of  this  information. 

7.  One  is  said  to  be  ‘in’  a  particular  scope  if  the  base  table  of  the  search  object  corre¬ 
sponds  to  that  particular  scope. 

1,2  A  Simplified  View  of  the  Symbol  Table 

The  various  symbol  table  packages  offer  the  programmer  a  great  deal  of  power  and  flexi¬ 
bility;  however,  most  programmers  of  ENCX)RE  tools  will  only  be  interested  in  a  rela¬ 
tively  small  set  of  operations.  These  include: 

•  determining  the  current  scope, 

•  creating  a  new  scope  within  a  given  scope, 

•  entering  a  previously  created  scope, 

•  leaving  a  given  scope  (returning  to  the  parent  scope), 

•  entering  the  scope  associated  with  a  given  declaration, 

•  retrieving  the  local  entry  (or  entries)  associated  with  a  given  key  in  a  given  scope,  and 

•  retrieving  the  entry  (or  entries)  associated  with  a  given  key,  visible  in  the  given  scope 
(i.e.,  those  entries  that  are  either  in  the  local  scope,  in  any  of  the  parent  scopes,  or  made 
visible  via  ‘with’  or  ‘use’  clauses). 

•  adding  an  entry  to  a  given  scope, 

•  removing  an  entry  from  a  given  scope, 

•  replacing  an  entry  in  a  given  scope  with  another  entry. 

These  operations  are  provided  in  the  package  Parser_Symbol_Table.  The  next  sections 

discuss  them  in  more  detail. 


1 J  Determining  the  Current  Scope 
The  routine 

function  Currcnt_Scopc  return  SymboLTable; 
returns  the  current  table  under  consideration. 

1.4  Creating  a  New  Scope 

To  create  a  new  scope,  the  programiiKr  invokes  the  following  routine: 
procedure  New_Scope(name); 
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where  ‘name’  is  the  name  of  the  Ada  program  unit  with  which  the  new  scope  is  to  be  asso¬ 
ciated.  This  procedure  creates  a  symbol  table  with  the  given  name  and  assigns  the  current 
scope  as  the  parent  table  of  the  new  table.  It  then  enters  the  newly  created  scope.  For 
example,  suppose  procedure  P  contains  a  subprocedure  PI,  Suppose  one  is  currently  in  the 
scope  of  P.  In  order  to  create  the  symbol  table  for  PI,  one  would  call  New_Scope  with  the 
designator  of  PI  as  the  parameter.  This  would  create  a  symbol  table  for  PI,  the  would 
place  the  search  cursor  in  the  scope  of  this  new  table. 

1.5  Changing  the  Current  Scope 

In  addition  to  the  New_Scope  routine,  thov  are  three  routines  for  entering  a  previously 
defined  scope.  These  are 

procedure  Enter_Scope(k); 
procedure  Leave.Scope; 
procedure  Enter_Associated_Scope(n); 

The  procedure  Enter.Scope  is  used  for  entering  a  previously  defined  subscope  of  the  cur¬ 
rent  scope.  In  this  procedure  ‘k’  is  the  name  of  the  scope  being  entered.  This  routine  sim¬ 
ply  enters  the  given  scope. 

The  procedure  Leave_Scope  simply  enters  the  parent  scope  of  the  current  scope;  thus,  a 
call  to  Entcr_Scopc,  followed  by  a  call  to  Lcavc_Scope,  will  result  in  the  current  scope 
being  the  original  scope. 

The  procedure  Enter_Associated_Scope  is  used  for  entering  the  scope  associated  with  a 
given  Ada  program  unit.  The  parameter  ‘n’  is  not  a  symbol  key  but,  rather,  an  AdaTran 
node  that  corresponds  to  a  particular  Ada  program  unit.  The  function  Enter_Associated_- 
Scope  allows  the  user  to  go  directly  to  a  given  scop>e,  without  having  to  go  up  and  down  a 
tree  of  nested  scopes.  One  example  where  this  is  important  is  searching  through  the  ‘used’ 
units  of  a  given  scope. 

For  example,  suppose  one  wishes  to  enter  the  scope  of  a  particular  compilation  unit.  The 
parameter  ‘n’  corresponds  to  the  unit  with  which  the  scope  is  associated. 

1.6  Retrieving  Symbol  Table  Entries 

Logically,  retrieval  of  symbol  table  entries  should  follow  the  visibility  rules  of  Ada.  This 
means  that  the  retrieval  process  generally  should  first  search  through  the  local  scope,  then 
the  parent  scopes  (in  order),  the  through  the  ‘with’-ed  units,  then  through  the  scopes  of  the 
‘used’-units.  Furthermore,  there  are  times  when  a  tool  may  wish  to  look  just  at  entries  in 
the  local  segment  of  the  current  unit  (for  example  just  in  the  ‘body’,  the  ‘private’  part,  or 
the  ‘specification’).  At  other  times  a  given  tool  may  be  interested  in  searching  through  all 
parts  of  the  current  scope  but  not  in  searching  through  any  of  the  parent  scopes. 
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In  Ada  there  can  be  more  than  one  declaration  with  a  given  key  visible  at  a  given  point  in 
the  program.  This  is  the  case,  for  example,  with  oveiloaded  subprograms.  In  order  to  deal 
with  multiple  visible  declarations  with  the  same  name,  we  have  introduced  the  notion  of  a 
'search  cui^r’  that  keeps  track  of  the  current  position  in  a  particular  search  through  a 
symbol  table.  Most  of  the  retrieval  routines  will  have  both  a  ‘Rrst_’  and  a  ‘Next_’  ver¬ 
sion.  The  function  whose  name  starts  with  'First.’  will  find  the  first  definition  correspond¬ 
ing  to  a  given  key,  starting  with  the  given  table.  The  function  whose  name  starts  with 
'Next.’  will  find  the  first  definitions  corresponding  to  the  given  key,  past  the  cursor  posi¬ 
tion  of  the  last  retrieval. 

One  final  note.  The  functions  for  retrieving  entries  all  use  the  parameter  'k,’  which  repre¬ 
sents  the  search  key.  The  type  of  'k’  has  not  been  specified.  This  is  because  these  functions 
are  all  overloaded  with  respect  to  'k,’  with  'k’  being  an  AdaTVan.Node  in  the  one  case  and 
'k’  being  a  Symbol  in  the  other  case.  In  the  case  where  'k’  is  an  AdaTan.Node,  'k’  must 
be  of  type  k.SymboI  or  k.Character.  This  is  to  allow  enumeration  literals,  some  of  which 
can  be  characters,  to  be  entered  in  the  symbol  table.  Since  nK>st  keys  will  be  symbols,  and 
since  many  tools  will  deal  exclusively  with  keys  that  are  symbols,  it  is  useful  to  ovedoad 
the  retrieval  functions  to  allow  symbols  themselves,  rather  than  just  symbol  nodes,  as 
keys. 

1.7  The  General  Search  Process 

The  general  search  process  is  to  search  for  all  visible  definitions  corresponding  to  a  given 
key.  This  facility  is  provided  by  the  functions 

function  Gct.First.Entry(k)  return  AdaTran.Node; 
function  Get.Next.Entryfk)  return  AdaTran.Node; 

The  function  Get.First.Entry  finds  the  first  entry  with  kev  'k’  visible  in  the  current  scope, 
while  Get.Next.Entry  finds  the  first  visible  entry  with  the  given  key  past  the  current 
search  cursor  position.  The  functions  Get.First.Entry  and  Get.Next.Entry  will  both 
search  through  all  definitions  visible  fiom  the  given  table,  whether  in  the  local  scope,  par¬ 
ent  scopes,  'with’-ed  units,  or  'used’-units. 

1.8  The  Local  Search  Process 

To  search  locally  in  a  given  scope  segment,  such  as  a  specification,  a  body,  or  a  private 
part,  one  uses  the  functions. 

function  Get.First.Local.Entry(k)  return  AdaTran.Node. 
function  Gct.Next_Local.Entry(k)  return  AdaTran.Node. 

These  work  similarly  to  Get.First.Entry  and  Get.Next.Entry,  except  that  the  search 
never  goes  beyond  the  current  segment. 
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1.9  The  Unit  Search  Process 


There  are  times  when  the  user  wishes  to  limit  searching  to  the  various  segments  of  an  Ada 
unit.  For  example,  one  might  begin  a  search  in  the  body  of  a  package  and  be  only  inter¬ 
ested  in  those  definitions  that  occur  in  the  body,  private  part,  and  specification.  Ilus  facil¬ 
ity  is  provided  by  the  functions 

function  Get_First_Unit_Entry(k)  return  AdaTran_Node; 
function  Get_Ncxt_Unit_Entry(k)  return  AdaTran_Node; 

1.10  Modifying  a  Symbol  Table 

The  basic  routines  for  modifying  a  symbol  table  are 

procedure  Add_Entry(k,  value); 

procedure  Remove_Entry(k,  value); 

procedure  Replace_Entry(k,  old_node,  new_node); 

These  three  routines  only  affect  the  current  scope. 

The  procedure  Add_Entry  simply  adds  the  entry  whose  key  is  given  by  the  parameter  ‘k’ 
and  whose  value  is  given  by  the  parameter  ‘value’  to  the  current  scope.  The  procedure 
Remove_Entry  deletes  the  entry  with  key  ‘k’  and  value  ‘value’  from  the  current  scope. 
Finally,  the  procedure  Replace_Entry  substitutes  the  value  given  by  ‘new_node’  for  that 
given  by  ‘old_node,’  under  the  key  given  by  ‘k.’ 

2.  The  Underlying  Symbol  Ihble  Mechanism 

A  complete  discussion  of  the  symbol  table  mechanism,  in  all  its  generality,  is  beyond  the 
scope  of  this  report.  This  section  merely  points  out  some  of  the  novel  features  of  the  sym¬ 
bol  table  mechanism. 

2.1  The  Building  Blocks  for  the  Symlxd  Ihble  Mechanism 
The  following  Ada  packages  make  up  the  symbol  table  mechanism: 

Associations 

Low_Lcvel_Symbol_Tablc_Definitions 

Symbol_Tablc_Functions 

Search_Functions 

12  The  Low  Level  Packages. 

The  packages  Associations  and  Low_LcvcLSymbol_’Ihblc_Definitions  provide  the  basic 
definitions  used  by  all  the  other  symbol  table  packages.  In  particular,  they  provide  the  def¬ 
initions  for  the  data  types  ‘Symbol_Table’  and  ‘Search,’  which  are  basic  to  all  the  other 
packages. 
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23  The  Package  *Syinbol_Table_Functioiis* 

The  package  SyniboI_Table_Functions  provides  facilities  for 

•  creating  new  symbol  tables, 

•  associating  symbol  tables  with  program  units, 

•  associating  symbol  tables  with  their  parent  and  descendant  tables,  and 

•  associating  symbol  tables  with  their  corresponding  ‘with’  and  ‘use’  clauses. 

2.4  The  Package  *Search_Functioiis* 

The  package  Search.Functions  forms  the  heart  of  the  symbol  table  mechanism.  It  pro¬ 
vides  the  mechanism  for  setting  up  and  manipulating  a  ‘search,  on  the  symbol  table  for  a 
given  Ada  program.  This  includes  facilities  for 

•  creating  new  searches, 

•  setting  the  base  (or  starting)  table  for  a  search, 

•  setting  the  mode  (LOCAL,  GLOBAL,  etc.)  of  a  search, 

•  handling  the  nesting  mechanism  for  a  search, 

•  setting  the  search  key  for  a  search, 

•  retrieving  symbol  table  entries  associated  with  a  given  search, 

•  adding,  removing,  and  replacing  entries  in  the  base  table  of  a  given  search. 

Note  that  the  word  ‘search’  in  this  context  refers  to  the  actual  Ada  data  type  ‘search,’ 
which  is  a  type  of  data  object  set  up  to  support  multiple  searches  through  the  symbol  table 
of  an  Ada  program. 

One  final  remark.  Most  tool  builders  will  not  use  the  packages  SymboLTable_Functions 
and  Search_Functions  directly.  Instead,  they  will  use  these  packages  via  a  simplified  inter¬ 
face,  such  as  that  provided  by  the  package  Parser_SymboLTable. 
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1.  INTRODUCTION 

This  memo  describes  the  program  tree  for  storing  Elementary  Statement  Language  (ESL) 
programs  in  a  tree  structure  in  memory.  Block  statements  are  nodes  that  have  branches  which 
fan-out  to  their  constituent  statements.  Terminal  statement  form  the  leaves  of  the  tree.  Each 
statement  is  also  the  root  of  a  subtree  of  expression  nodes  that  contain  the  arguments  of  the 
statement  This  memo  consists  of  four  sections.  Section  2  discusses  the  statement  and 
expression  node  structures.  Section  3  describes  the  structure  for  storing  executable  statements. 
Section  4  describes  the  node  structure  for  storing  ESL  declaration  statements.  Section  5 
discusses  the  expression  nodes  structure.  The  ESL  tree  is  used  as  an  intermediary  in  translation 
of  source  real-time  programming  languages  into  Ada.  A  source  language  program  is  translated 
first  to  ESL.  ESL  has  semantics  similar  to  those  of  Ada.  However,  the  ESL  tree  is  reorganized 
and  modified  prior  to  translation  to  Ada. 


2.  DATA  STRUCTURE  OF  STATEMENT  AND  EXPRESSION  NODE  IN  THE 

PROGRAM  TREE 

2.1.  DATA  STRUCTURE  OF  THE  PROGRAM  TREE  STATEMENT  NODES 

This  subsection  describes  the  node  structure  of  statements.  The  statement  node  structure  is 
shown  'below  in  MODEL,  C,  and  Ada  in  a  structure  of  type  node. 
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1  aod*  la  typ*  aeeaaaad  bp  bodaPtr, 

3  langnapa  la  fXd(^ar  1).  asSL*/ 

3  atat^tppa  la  fid  (bln  fin) ,  /•mtmk  tppaV 
3  atnt^non  la  fld(bln  fix),  /aatab  Id  noabar*/ 

3  anx  la  fld(aaeaaa)  bnxIlodaPtx.  /*attrlbatn  flald  for  fntnro  nao*/' 

3  oneedal  la  fld(ebar  1),  /aonooda  atataaamt  pelataraa/ 

3  aneedaZ  la  fid  (<d>az  1) ,  /*aneeda  axpaaaaloo  polntara*/ 

3  fatbar  la  fld(aaeaaa)  MedaPtr,  /aixoMdlata  aaoaatar*/ 

3  pbrotbar  la  fld(aeeoaa)  bodaPtr.  /apraalana  albllag  atat*/ 

3  nbxotbar  la  fld(aoaoaa)  bodaPtr,  /anaxt  albllag  atad*/ 

3  t_aon  la  fld(aeaoaa)  RodaPtr,  /atban  aoa*/ 

3  a_aoa  la  fld(aeeaaa)  bedaPtr,  /*alaa  aon*/ 

3  labal_palntar  la  flald  (aooaaa)  IXPIIodaPtr, 

3  axO  la  fld(aeeaaa)  SWodaPtr, 

3  0x1  la  fid  (aooaaa)  nraodaPtr, 

3  0x2  la  fid  (aooaaa)  UFModaPtr; 

typadaf  Int  atab_klad; 
tppadaf  ehax  laagoagaa; 

atruet  _>eda  ( 

langoagaa  languaga; 

atab_lclnd  atat_tppa; 

ehar  atnt_nan(3];  /*  itatOMOt  aaqoonoa  nunbar  in  tha  program  •/ 

/*  It  takaa  ■  obaraotar  peaitlona  */ 
atraet  _Aiameda  *atix;  /*  attrlbota  neda  for  fntnra  naa  */ 

ohar  anoodal,  aaooda2; 

/*  anoodal  anoodaa  tba  5  atroetnza  pointara  */ 
/*  anoodal  anoodaa  tba  3  aapraaalon  pointara*/ 
atmot  _lloda  *fathar;  /*  tba  fatbar  atatanaot  */ 

atraet  jRoda  *pbrotbar;  /*  tba  praalona  albllng  atataawnt  •/ 

atraot  _lleda  •nbrotbar;  /*  tba  naxt  albllng  atatamant  •/ 

atraet  .Rada  •t^aoo; 

/*  tba  flrat  atataawnt  of  tba  */ 

/*  block  If  tba  eorront  noda  rapraaanta  a  */ 

/*  oonpoond  atatowant.  If  It  la  an  */ 

/*  ' If-tban-alaa' ,  It  polnta  to  tba  flrat  */ 

/*  atatawaot  of  tba  'than'  block.  */ 

atraot  _RodB  •o_aea; 

~  /•  tba  flrat  atatowont  of  tba  •/ 

/*  'alaa'  block  If  It  la  an  'If-tbao-alaa'*/ 

/*  atatawaot  and  If  tbara  la  an  'alaa*  */ 

/*  block,  'RUU,'  otharwlaa.  •/ 

at  met  _R]700da  *labal_polntor; 

atraet  Rxpooda  *axO,  *oxl,  *0x2; 

); 

mx  RODS  IS  RBC0N» 

UUKSOMR:  CRMUCTIR; 

37MT_nPR:  1RTR6RR; 

STia~Rm:  nmcRR; 

KOX  :~MnoiOORtnt; 

RRCODIl:  CRaWkCVIR; 

SRC0DR2:  CBWbCTlR; 

PkTBRR:  ROOVTR; 

PRR0TR1R:  RODRPTR; 

RRROTHRR:  ROORPTR; 
f_«OR:  WOOXnX; 
ujxox:  Romm; 

ljaRL_POZRtRR:  IXPRODRPm; 

RXO:  ilPROORPfR; 

■Zls  MRPROBtftR; 

1X3$  RXPROORPTR; 

IRD  RXCCM); 
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This  structure  is  graphically  described  as  follows: 


Three  expression  pointers  exO,  exl.  and  ex2  are  used  to  store  statement  arguments  in 
expression  nt^es.  The  fields  of  the  statement  structure  are  as  follows: 

2.1.1.  LANGUAGE 

This  field  is  reserved  for  temporary  and  future  use  to  denote  the  translation  from  a  source 
language  to  a  version  of  ESL.  It  indicates  the  need  to  reorder  the  programs  and  to  use 
procedures  that  correspond  to  source  program  special  functions  and  operating  system  calls.  This 
must  be  done  in  the  translation  from  ESL  to  Ada. 


2.1.2.  STATEMENT  TYPE 

Statement  types  are  discussed  in  Section  3  toe  executable  statements  and  in  Section  4  for 
declaration  statements.  The  statement  type  are  represented  in  this  memo  by  symbolic  names. 
The  statement  types  are  listed  in  the  tables  in  Section  3  and  4.  The  corresponding  identification 
number  of  each  statement  type  is  given  in  Appendix  L 

1.13,  AUXILIARY 

This  field  is  reserved  tar  temporary  use  in  the  processing  of  an  ESL  tree. 
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2.1.4.  ENCODEl  AND  ENCODE! 

Encodel  and  Encode!  are  represented  each  by  one  character.  Encodel  encodes  the 
presence/absence  of  4  structure  pointers: 

pbrother 

nbrother 

t^son 

e_son 

The  presence/absence  of  each  pointer  above  is  a  binaiy  number  in  this  order.  The 
presence/absence  of  the  above  four  pointers  is  encoded  by  one  of  the  following  16  characters: 

Since  every  statement  (except  the  root)  has  a  father  pointer,  the  presence  of  the  father 
pointer  is  not  encoded. 

For  instance,  encodel  =  ’7*.  corresponds  to  the  binary  number 

0111 

from  the  encoding  rule,  we  find 

pbrothar  «  null 
nbrothar  /*  null 
t_son  /■  null 
•_«on  />  null 

Similarly,  the  character  encode!  encodes  use  of  four  expression  pointers: 

l«b«l_pointnr 

•xO 

•xl 

•x2 

as  one  of  the  16  characters: 


0,1,2, 3,  4,5,  6,7,S,  9,  A, B, C, O,  B, F 

Encodel  and  Encode!  are  also  used  to  unload  the  program  tree  to  a  disk  file  in  depth  first 
left  to  right  order  and  to  load  back  the  didr  file  to  memory  and  rebuild  the  tree. 
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2,1J5.  STRUCTURE  POINTERS 

A  statement  is  graphically  portrayed  as  having  five  pointers  to  its  neighbors,  if  any. 


1 

£ath*x 

pbrothttr  f 

\  nbxotlMx 

L 

j - ^ 

t  son 

•  aon 

2.1.6.  LABEL_POINTER 

This  field  contains  the  pointer  to  a  label  expression,  if  any.  Its  presence  is  included  in 
encode2. 

2.1.7.  EXPRESSION  POINTERS 

There  may  be  as  many  as  three  main  expressitms  representing  the  arguments  of  each 
statement  The  existence  of  such  expressions  is  coded  in  encode2.  Each  expression  may  consist 
of  further  subexpressions,  as  discussed  further. 
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2.2.  DATA  STRUCTURE  OF  EXPRESSION  NODES 

An  expressions  node  has  a  structure  of  type  expnode.  Following  is  the  deflnition  of  the 
structure  in  MODEL,  C,  and  Ada: 

1  •xpnodm  i«  typ*  aceasaad  by  Bi^odaFtr, 

3  •xpjtyp*  la  fld(bln  fix), 

3  nb  Is  £ld(bin  £is) , 

3  nbrothar  la  £ld(aeeaaa)  KxpnodaPtr, 

3  no_o£__d«ae  la  £ld(bla  £lx), 

3  point (3)  la  £ld(aeeaaa)  XxpnodnPtx, 

3  no_o£_cbar  la  £ld (bln  £lx) , 

3  atxjraln*  la  £ld(char  (*));  /*  Tnrlabln  langth  flald  */ 

typ«l*£  Int  axpjilnd;  /*  MC  */ 

atruet  _Xzpnoda( 

•xp_Jclnd  aapjbypa;  /*  Munarle  coda  of  tha  axpraaalon  */ 

int  nb;  /*  Xtla01£nbxotb«r  la  IIOZ.L,  1  otharwlaa  */ 


atruet  _JB3^noda  *nbrothar;  /*  Polntac  to  naxt  brothar  */ 

int  no^ofjdaac;  /*  Huater  of  aona  of  currant  noda  */ 

atruet  _JExpnoda  *polnt(3];  /*  Polntara  to  aona  of  tbla  noda  */ 

Int  no_o£_char;  /*  Laogth  of  atrjaalna  */ 

char  atr_7alua(€4]  ; /*  Vaclabla  langtb  string  Talua,  up  to  4046  */ 

)  ; 

TYPE  EXPNODE  (U3l_STR_yALOX:  intagar:«0) 

XS  RECORD 

EXPjrXPE:  XNTEGBR; 

nb:  integer; 

NBROTBER:  EXPNODEPTR; 

NO^OrjDBSC:  XNTEGER; 
ponirT  EXP_VECiOR  (1 . .  3)  ; 

NOjOrjCBAR:  XNTEGBR; 

8TRJDU4IE :  STRING  (1 . .  X4EN_8TR_Viatre)  ; 

END  RECORD; 

where 

TYPE  EXP  VECTOR  X8  ARRAY  (POSITIVE  RANGE  O)  OP  EXPN(»XPTR; 
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This  structure  is  gn4>hically  described  as  follows: 


Each  field  of  the  structure  expnode  is  explained  in  the  following. 

2.2.1.  EXPRESSION  TYPE 

The  field  exp_typc  is  an  integer  which  identifies  the  type  of  the  expression.  The  expression 
types  and  respective  numbers  are  given  in  Section  5. 


2.2.2.  POINTERS  TO  BROTHER  EXPRESSION 


The  field  nb  recotds  the  presence  (nb=l)  /  absence  (nb=l)  of  next  expression  nbrother.  This 
enables  creating  a  sequence  of  expressions.  For  instance,  a  function  definition  may  have  several 
formal  parameters. 

■  far_8PBC 
•xO  ->  fanetlon^jMM 
«xl  ->  p«raMt«x«  pi,  p2,  p3 
•x2  ->  data  typo  of  xatnxii  valua 

The  structure  of  such  a  statement  is: 


•xl 


1 


pi 

P2 

nbrothar 

nbrothar 

P3 

.nbrothar 


null 


2.23.  NUMBER  OF  DESCENDANTS 

The  field  no.oLdesc  records  the  number  of  sons  of  the  current  node.  When  the  node  is  a 
terminal  node,  it  has  zero  descendants. 
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2.2.4.  POINTERS  TO  DESCENDANTS 

The  field  point  is  an  anay  of  pointers  to  son  expression  nodes.  It  is  a  three  element  array. 

2.2.5.  NUMBER  OF  CHARACTERS  IN  STRING 

The  string  str.value  has  a  variable  length.  The  length  (number  of  characters)  of  the 
str_value  field  is  recorded  in  this  field.  A  value  of  0  in  this  field  indicates  that  the  str.value  field 
of  the  expression  node  is  not  used. 

2.2.6.  STRING 

This  field  str_value  of  the  USAGE_EXPR  (see  Section  S  for  expression  types)  is  used  to 
store  the  function  of  some  expressions  as  follows. 


VALUE 

MEANING 

COMMENT 

@C 

an  inline  comment 

DELTA 

@D 

precision  of  a  fixed  type. 

ENUMER 

@E 

a  list  of  enumerated  data  types. 

INITIAL 

@I 

initial  value. 

LAYOUT 

@Y 

bit  range  of  component 

LENGTH 

@L 

the  length  of  a  record  in  terms  of  bits. 

NEW 

@N 

new  instantiaticHi  of  type  or  generic  name. 

PACKING 

@P 

word  and  byte  information  for  a  variable 
packing  clause. 

RANGE 

<§>R 

range  of  a  scalar  type. 
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3.  EXECUTABLE  STATEMENTS 


The  executable  statements  in  ESL  are  listed  in  the  following  table. 


STATEMENT  TYPE 

STATEMENT  SUBTYPE 

STMT_TYPE  NAME 

1. 

Condition 

if-then-else 

IF_STAT 

Block 

case 

CASE.STAT 

when 

WHEN_STAT 

2. 

Loop 

while 

WHILE.STAT 

Block 

until 

UNTIL_STAT 

fCM* 

FOR_STAT 

3. 

Assignment 

Terminal 

assignment 

ASSIGN.STAT 

1 

Procedure  Call 

Terminal 

call 

raise  exception 

CALL.STAT 

RAISE.STAT 

5. 

Message 

Terminal 

send/receive  message 
accept  message 

MSG_CALL 

MSG_ACCEPT 

6. 

Input/Output 

read 

READ^STAT 

Terminal 

write 

WRTTE.STAT 

m 

lA)  Auxiliary 

open 

OPEN^FILE 

Terminal 

close 

CLOSE.FILE 

■ 

position 

POSmON.FILE 

8. 

Context 

with 

WTTH.STAT 

Terminal 

use 

USE.STAT 

program.separate 

PACK_SEP 

PROC.SEP 

FCN.SEP 

TASK_SEP 

separate 

SEPARATE.STAT 

pragma 

PRAGMA 

9. 

Control  Transfer 

return 

RETURN_STAT 

Terminal 

go-to* 

GOTO 

exit* 

EXIT 

null* 

NULL 

*  Statements  eliminated  in  later  processing  of  ESL. 


The  expressions  used  with  each  statement  type  are  discussed  below. 
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3.1.  CONDITIONAL  BLOCK 

A  condirional  block  can  be  of  types  IF_STAT,  CASE_STAT  and  WHEN^STAT. 

IF_STAT  statements  represents: 

ir  <condltloii>  THXM  <Btat«aientsl>; 

(KLSK  <atat«Bants2>) 

<condition>  is  a  Boolean  expression.  The  ESL  statement  format  is: 

8tait_typa  ■  ll'_8TAT; 

•zO  ->  <condltlon>; 
t_8on  ->  <stat«Mnt«l>; 

•  aon  ->  <8tataaMnts2>,  if  any; 


A  CASE_STAT  statement  represents  choice  of  one  of  several  blocks  <statcmentsl> . 

<statementsn>  according  to  the  values  valuel.  ...»  value  n.  The  CASE  statement  contains 
blocks  of  WHEN  and  ELSE  statements.  Each  of  these  blocks  contains  the  respective 
<statementsi>: 

The  format  of  the  CASE  statement  is: 

stat__typa  «  CASK^STAT; 

azO  >>  <azpra8slon>; 

t_son  >>  <fiz8t  WHKH  statamant> 

a_aon  •>>  <flc8t  statanent  undar  tha  ELSE  atatamant,  if  any> 

The  format  of  the  WHEN  statement  is: 

atait__typa  *  1IHEN__8TAT 

azO  ->  <Taluai>; 

t  aon  ->  fizat  of  atataaantl; 


The  CASE  statement  tree  representation  is  illustrated  below. 
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3.2.  LOOP  BLOCK 

The  loop  statement  has  three  forms:  WHILE_STAT,  UNTIL_STAT,  and  FOR_STAT. 
A  WHEJE_STAT  statement  represents: 

NHiuB  <condltloo> 

It  is  followed  by  descendants  forming  the  loop  body. 

<condition>  is  a  boolean  expression. 

The  ESL  format  is: 

stint^typ*  ■  1IHIU_STAT; 

•zO  ->  <condltlon>; 

t_aon  ~>  first  statemsnt  in  loop  body; 

An  UNTIL_STAT  statement  represents: 

DO  DMTXL  <eondltlon>; 

The  ESL  fonnat  is: 

statt_typ«  ■  tJHTIl._SIAT; 

•xO  ->  <eottdltion>; 

t_8on  *>>  first  ststsannt  in  loop  bo<^; 
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A  FOR^STAT  statement  represents: 

FOR  <loop  ▼arlabl«>  ■  FROM  <lnltl«l  TRR0  <fin«l  ▼alu«> 

[BT  <stap  lftng'th>] 

Its  ESL  format  is: 

atait_typ«  »  FOR_SIAT; 

•zO  ->  <loop  ▼•zlabl*>; 

•zl  ->  <lnitlal  ▼alu«>,  <Final  ▼alua>,  <atap  langrth>; 
t._son  ->  £lrst  atataaant  in  loop  bod^; 

33.  ASSIGNMENT  STATEMENT 

An  assignment  always  has  a  left  hand  side  variable  and  a  right  hand  side  expression.  It  has 
the  ESL  format: 

Stflit_typ«  ■  ASSX(af_STAT; 

•zO  ->  tha  la£t  hand  aida  vazlabla (a) ; 

->  tha  right  hand  alda  arpraaaion; 


3.4.  PROCEDURE  CALL 

This  statement  represents  regular  as  well  as  operating  system  calls.  The  source  program 
may  call  the  operating  system  to  provide  certain  services.  Operating  system  calls  in  a  source 
language  for  input/output  and  tadc  communication  are  represented  by  ESL  statements  in  the 
Input/Output  (Section  3.5)  and  Message  (section  3.6)  categories  described  below  respectively. 
Other  operating  system  calls  are  handled  as  this  type  of  procedure  call  statement. 

The  ESL  format  for  a  procedure  call  is: 

■tnt^typo  «■  CALL_SIAT; 

•zO  *■>  noam  of  tho  procoduro; 

•zl  ->  list  of  paraflwtors; 

exl  points  to  a  list  of  parameter  expressions.  Each  parameter  expression  consists  of  a  parameter 
naiiK. 

Operating  system  calls  in  a  source  language  program  perform  a  variety  of  functions  which 
may  not  have  a  direct  equivalent  in  Ada.  Their  call  name  and  parameters  will  be  stored  for  later 
analysis.  Operating  system  calls  for  task  messages  and  I/O  are  discussed  separately  below. 

The  ESL  format  for  a  RAISE  statement  is: 

•tat_typo  ■  RAISR_STAT 
•zO  ->  nano  of  ozcoption 
•zanplo:  RAI8B_8TAT  (KRROR); 
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3^.  MESSAGE  STATEMENTS 

These  statements  are  used  to  indicate  communications  between  tasks.  There  are  two 
statement  types.  MSG.CALL  is  used  when  the  calla  specifies  die  name  of  the  other 
communicating  task.  MSG_ACCEPT  is  used  when  the  communication  may  involve  unknown 
other  tasks.  A  communication  must  pair  a  MSG.CALL  in  one  task  with  a  MSG_ACCEPT  in 
another  task.  Their  ESL  format  is: 

•tait_typ*  *  NSGjCAZiL 

•xO  ->  namm  of  a  procodux*  usod  to  iatoxpxot  a  aaesaaga  sond/xacalTO 
operation  of  aouxee  program, 
exl  ->  list  of  paranetars  with  modes 
ez2  ->  a  list  of  task  and  entry  names 

stmtjtype  -  NS6_ACCUT 

ezO  ->  name  of  a  procedure  used  to  interpret  source  program  send/recelve 
exl  ->  list  of  parameters  with  nodes 
ex2  ->  entry  nastas 

3.6.  INPUT/OUTPUT 

Input/OuQiut  statements  represent  I/O  activities  in  the  source  language  or  its  operating 
system.  The  ESL  format  provides  for  storing  the  operating  system  cdl  name  and  its  arguments 
as  follows: 

stmt_type  MEaojBTAT  (for  ii^t)  or 

'  1IRXn_STAT  (for  output) 

exO  ->  name  of  a  procedure  that  interprets  the  operation  of  the  source 
language  and  operating  system  I/O 
exl  ~>  list  of  paraamters 
ex2  *•>  file  nasm,  format 


3.7.  INPUT/OUTPUT  AUXILIARY  STATEMENT 

There  are  three  input/output  auxiliary  statements;  OPEN^FILE,  CLOSE.FILE,  and 
POSrnON_FILE.  They  are  stored  as  follows. 

stmtjtype  ■  OPBNJTXLB,  CIi08l_rXLB  or  POSXTXOMMTXLB 
exO  ->  procedure  name  that  interprets  source  program  X/0  auxiliary 
eosmands.  Bnpty  ea^ression  ()  if  not  applicable, 
exl  ->  list  of  parameters 
ex2  ->  file  name 


3.8  CONTEXT  STATEMENTS 

These  statements  indicate  that  definition  of  a  program  entity  is  dependent  on  other 
definitions  or  incomplete. 

WrrH_STAT  and  USE.STAT  refer  to  other  packages.  The  fonnat  is 
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■■  WZTHJBTAX  or  USBjBTAT; 

•xO  ->  paekago  iuoms  for  T78K_8VAS 

packaga  and  program  unit  nano  for  VITBjBTAT  ; 

PACK_SEP,  TASK_SEP,  PRCXLSEP  and  FCN_SEP  are  used  to  indicate  that  the  body  of 
these  program  units  (package,  task,  procedure  or  function,  respectively)  is  provided  elsewhere 
and  compilable  separately  in  Ada.  The  format  is: 

statjbypo  «  PACK_8TAT,  TASK_8BP,  PnOC_8XP  or  rCII_8BP 

There  are  no  aiguments.  This  is  a  terminal  statement  with  the  respective  program  unit 
specification  as  the  parent 

The  SEPARATE.STAT  statement  is  used  to  indicate  that  the  body  of  a  program  unit 
follows,  where  the  specification  is  in  another  package.  The  format  is 

Stat^typO  *  SXPARATK_8TAZ 
•xO  packago  nama  wharo  tinlt  apaeiflad 

This  is  a  terminal  statement  preceding  the  program  unit  body  declaration. 

The  PRAGMA  statement  provides  information  used  in  the  con^ilation.  The  format  is: 

stat^typo  ■  PRAGMk 
axO  m  pragma  nama 
axl  «  liat  of  attrlbutae 


3.9  CONTROL  TRANSFER 

A  return  statement  returns  the  control  from  a  called  procedural  or  function  to  a  calling 
procedure  or  function.  A  return  statement  may  include  an  expression  for  a  returned  value. 

A  return  statement  is  stored  as: 

atnb_typa  >  MIT0iav_8TAT; 

axO  '>  ajqpraaaioa,  if  any; 

The  following  three  suitements  extend  ESL:  GOTO,  EXIT,  NULL.  These  statements  can 
have  one  or  more  labels.  They  are  eliminated  in  later  processing  of  ESL.  Each  of  these 
statements  is  stored  in  a  node  statement  structure,  as  a  terminal  ESL  statements. 

A  Goto  statement  has  its  usual  meaning. 

GOTO  <labal>  -v 

The  format  is: 

stsit_typa  «  GOTO_8TAT; 

axO  ->  <labal> 

axl  ->  procaduza  or  function  nama;  if  <labal>  is  not  in  tha  scopa  of  tha 
iamadiata  anelosing  procaduza  or  function. 
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An  EXIT  statement  nested  in  a  lo(^  transfers  control  to  the  statement  following  the  end  of  a 
nesting  loop.  If  an  EXIT  (toes  not  have  a  label,  the  control  always  transfers  to  the  end  of  the 
inunediate  nesting  toop.  If  an  EXIT  statement  has  a  label,  the  control  transfers  to  the  end  of  the 
labelled  loop.  The  labelled  l(x^  must  nest  the  EXIT  statement 

The  format  is 

atait_typ«  •  EXIT; 

•zO  ->  <lab«l>; 

A  NULL  statement  provides  a  holder  for  a  statement  label,  as  the  destination  of  a  GOTO 
statement  A  NULL  statement  format  is: 

8t]Bt_typ«  >  MOLL; 
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DECLARATION  STATEMENTS 
The  table  below  summarizes  the  ESL  declaration  statements. 


STATEMENT  TYPE 

STATEMENT 

SUB_TYPE 

STATEMENT  NAME 

Program  Type: 

task 

TASK^TYPE 

Block 

generic  program 

PACK_GEN 

PROC_GEN 

FCN.GEN 

Structure  lype: 

Block 

recmdtype 

RECORD.TYPE 

Variable  Type: 

Terminal 

variable  type 

VARIABLE.TYPE 

Program  Unit: 

system 

SYSTEM 

Block 

program  file 

PROGRAM_nLE 

package 

PACieSPEC 

task 

TASK.SPEC 

procedure 

PROC_SPEC 

function 

FCN_SPEC 

1 

program  body 

PACK.BODY 

PROC_BODY 

FCN^BODY 

TASK_BODY 

begin-end 

BEGIN 

exception 

EXCEPnON.DCL 

EXCEPnON_HNDLR 

select 

SELECT 

Structure  of  Variable: 

Block 

record 

RECORD 

Variable: 

variable 

VARIABLE 

Terminal 

constant 

CONSTANT 

Hie: 

i/ofile 

IO_FILE  i 

Terminal 

i/o  device 

lO.DEVICE 

j 

task  entry 

TASK.ENTRY 

Comment: 

; 

ordinary 

ORD_COMMENT 

preprocess 

PREP.COMMENT 

compiler 

COMP_COMMENT 

debugging 

DEBUG.COMMENT 

These  types  of  statements  are  fmther  described  below. 
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4.1  PROGRAM  TYPE 

Task  type  is  stored  in  the  ESL  program  tree  as  follows: 

•tnt_t7p«  -  TASKjrXPB 
•zO  ->  typ«  nuami 

\ 

There  are  three  generic  statement  types  fw  package:  PACK_GEN,  for  procedure: 
PROC.GEN  and  for  function:  FCNjGEN.  They  have  the  following  points. 

•tat_typ«  •  PACK_GBI,  PROC^JSSN  or  ^C1I_GEN 
•zO  ->  nuam 

t_son  ->  flzst  geozrie  fozsal  pzrazMtzr 

youngest  sibling  of  t_son  ->  specification  of  generic  program  unit 
This  is  illustrated  in  the  figure  below. 


PACK.SPEC 

PROC.SPEC 

or 

FCN_SPEC 


exO  ->  name  of  generic  unit 


t_son 


first  generic 
formal 
parameter 


specification  of 
generic  unit  j 


STRUCTURE  TYPE 


A  record  type  declaration  whidi  has  the  following  format: 

stmtjtype  >  RECOBOjmK; 
ezO  ->  type  name; 
ezl  ->  length 

t_son  ->  first  entity  of  the  record;^. 
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4.3  VARUBLETYPE 

The  variable  type  declaration  is  stored  as: 

stiBt_typ«  ■  V»lUABLB_'mK; 

•xO  ->  type  nana; 

•xl  ->  typ«  daflnition,  rang*,  •nunaratlon  typ«  valoas,  , 
initial  valua,  length*  packing  and  layout. 

%x2  ->  dlnansion  xangea,  if  any; 


4.4  PROGRAM  UNIT 

A  program  unit  declaration  is  a  block  statement  It  denotes  begin-end.  a  system,  a 
subsystem,  a  package,  a  task,  a  procedure  or  a  function. 

Begin_end  has  the  following  format: 

etiiit_typa  ■  BEGIN; 

t__son  ->  first  statement  in  the  block; 

A  system  or  subsystem  head  is  stored  as: 

stait_typa  ■  8TSTEH; 

•xO  •>>  system  or  subsystem  nasta; 
t_.aon  ->  first  stataamnt  in  a  system; 

A  package  or  a  task  do  not  have  parameters.  Their  format  is 

stmt_type  ■  PACK^SPBC  or  TASK_SPBC 

axO  ->  name,  [name  of  generic  package  being  instantiated] 

Their  body  block  has  a  similar  format: 

stmt_type  ■  PACK_BOOT  or  TASK_BODT 
exO'*>  name 

t_son  ->  first  statement 

Note:  there  is  no  PACK_BODY  of  the  package  instantiate  a  generic  package. 

A  function  may  have  multiple  IN  mode  parameters  and  returns  a  value.  A  procedure  may 
have  none  or  multiple  IN,  OUT  and  INOUT  mode  (including  no  value  at  all). 

A  function  format  is: 

•tmt_type  «  rCN__SPEC; 

function  name,  [name  of  generic  function  being  instantiated] ; 
formal  parameters;  (or  generic  formal  parameters 

if  the  function  is  an  instance  of  a  generic  function) ; 
ex2  ->  type  of  return  ralue; 
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A  function  body  is  suxed  similarly  u: 

atat_typ«  •  rCM_BOOT; 

•zO  **>  fonetloa  n«ma; 

•zl  ->  Input  formal  paramntars,  namaa  and  typaa 
az2  ->  typa  of  ratum  Talua; 
t_aon  ~>  firat  atatamant; 

Note;  there  is  no  function  body  if  it  is  an  instantiation  of  a  generic  function. 

A  procedure  is  stored  as: 

ataA._typa  ■  PR0C__SP1C; 
azO  ->  procaduza  nama; 

azl  ->  formal  paraamtaz  nama,  oodo,  and  typa  oz  ganarle  formal  pazamataza 
If  tha  function  la  an  Inatanca  of  a  genazle  function; 

The  body  of  a  procedure  is: 

atmt_typa  ■  PROC_B(»T; 
azO->  pzocaduza  nama; 

azl->  fozmal  paraamtaz  nama,  typaa,  amda  and  default  zalua; 
t_aon  ->  flzat  atatamant; 

Note:  there  is  no  procedure  body  if  it  is  an  instance  of  a  generic  procedure. 

The  storage  of  a  parameter  in  a  function  or  a  procedure  declaration  is  further  explained 
below. 

Each  formal  parameter  may  have  a  name,  a  mode,  a  data  type,  and  a  default  value.  These 
associated  attributes  are  stored  in  expression  data  structure  expnodes  as  follows: 

exl->  expnode  cxp_typc:FORMAL_|*ARA; 
nbrother.  points  to  next  parameter; 

no_of_dcsc:  3; 

point(l):  points  to  a  NAME  expnode  which  contains  the  parameter  mode; 

That  is,  one  of  TN”,  "OUT”,  or  ’TNOUT’; 
point(2):  points  to  a  NAME  expnode,  which  contains  the 

data  type; 

point(3):  points  to  an  expression  expnode,  which  is  the  default  value 

of  the  pararoetet; 

no_of_char:  length  of  the  parameter  name; 

str.value:  parameter  name; 

The  formats  fcv  EXCEPTION  and  SELECT  are 

•tmfc_typ«  >  XXCXPTXOM 
•zazplu:  KXCKPTION; 

(duscendznta  azu  tha  HRKM  <condltloiis>) 

atmt_typ«  *  SCLICT 
azampla :  SKXJBCT 
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This  is  illustrated  below: 

- 1’ 


4.5  STRUCTURE  DECLARATION 

A  record  declaration  is  of  a  single  or  an  array  of  records.  This  declaration  is  stored  in  the 
program  tree  as: 

•t*t_type  ■  lUEOORD; 

•zO  ->  record  name; 
ezl  ->  type,  length; 

•x2  ->  diaenelott  ranges; 

(if  ex2*null.  It  represents  a  single  record) ; 
t_son  ->  first  field  of  the  record; 

The  fields  ate  stored  as  descendents  of  the  lecoid. 
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4.6  VARIABLE 

There  are  two  declarations  in  this  category:  variable  and  constant  declarations.  They  are 
stored  in  the  program  tree  as  follows. 

variable: 

stJBt_typ*  >  VJUOABLI; 

•xO  ->  ▼ariabl*  naaa; 

•xl  >>  type,  rang*,  initial  valu*,  packing,  length; 

•x2  ->  dixoansion  ranges; 

(if  •x2Bnull,  it  rapraaants  a  singl*  Tariabl*) ; 

constant: 

stiBt_typ«  ■  COHSTMIT; 

•xO  ->  constant  naa*; 

•xl  ~>  typ*,  valu*,  packing,  length; 

•x2  ->  diiaension  ranges; 

(if  ex2enull,  it  represents  a  single  constant) ; 


4.7  FILE 

A  file  declaration  of  a  file  is  stored  as: 

otint_type  »  lOjrxui,  lOJDEVXOI; 
exO  ->  file  nans; 
exl  ->  list  of  parameters; 
ex2  ->  <file  type> 

<file  type>  could  be  'sequential',  'post', 

'nail',  'isaa',  'rel',  'screen',  'direct'  or  others  used  in  the 
source  language  or  operating  system. 

A  task  entry  is  declared  as: 

Stmtjtype  >  TAS1C_ENTRX 
•xO  ~>  nams 

•xl  ->  list  of  parameters,  siodes  and  types. 


4.8  COMMENT  DECLARATION 

A  comment  may  originate  in  a  user  comment,  a  keyword  or  comment  in  the  source  language 
program.  Additionally,  a  source  language  keyword  may  be  stored  as  a  comment  expression.  It 
may  affect  the  translation  of  a  program  from  ESL  to  Ada. 

There  are  four  kinds  of  comments;  ordinary  user  comment  and  source  language 
preprocessor  command,  compiler  command,  or  debugging  command: 

Their  format  is 

stmt^type  -  ORDJCOHMIMT,  PRKPJCOKKEMT  aSNPJCOMMEMT, 

“  ex  DKBOGjCOMKENf  “  “ 

•xO  <->  comment 
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1^  5.  EXPRESSION  NODES 

5.1  TYPES  OF  EXPRESSION  NODES 

I 

*  The  table  below  describes  the  type  of  expnodes. 

1^  Logical  Expressions 

f 


Code 

Expr  Name 

Operation 

Operator 

Example 

11 

GT_EXPR 

greater  than 

> 

a  >b 

12 

GE_EXPR 

greater  than  or  equal  to 

>= 

a  >=b 

13 

EQ_EXPR 

equal  to 

= 

a  =b 

14 

NE.EXPR 

not  equal  to 

h 

a/=b 

IS 

LT.EXPR 

less  than 

< 

a  <b 

16 

LE_EXPR 

less  than  or  equal  to 

<= 

a  <=  b 

Code 

Expr  Name 

Operation 

Operator 

Example 

1 

OR_EXPR 

inclusive  disjunction 

OR 

aORb 

2 

XOR.EXPR 

exclusive  disjunction 

XOR 

aXORb 

3 

AND_EXPR 

conjunction 

AND 

aANDb 

4 

NOT.EXPR 

logical  negation 

NOT 

NOT  a 

Relational  Expressions 


Arithmetic  Expressions 


Code 

Expr  Name 

Operation 

21 

PLUS^EXPR 

addition 

identity 

22 

MINUS.EXPR 

subtraction 

negation 

23 

TIMES.EXPR 

multiplication 

24 

D1V_EXPR 

division 

25 

EXPNT_EXPR 

exponentiation 

26 

MOD.EXPR 

nxxlulus 

27 

REM_EXPR 

remainder 

28 

ABS_EXPR 

absolute  value 

Operator 


MOD 


REM 


ABS 


Example 


a  +  b 
+3, +a 


a  -  b 
-22.5. -a 


a  *b 


a/  b 


a  ♦•b 


a  MODb 


a  REMb 


ABS  a 
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String  Concatenation 


Code 

Expr  Name 

Operation 

Operator 

Example 

31 

CONCAT.EXPR 

concatenation 

& 

DBBHIi 

Miscellaneous 


Code 

Expr  Name 

Operation 

Operator 

Example 

41 

PAREN^EXPR 

parentheses 

(  ) 

(a+b) 

42 

SUBSCR_EXPR 

subscripts 

(  ) 

a(i,j.k) 

43 

FUNCTION J£XPR 

function 

(  ) 

f(a,b) 

44 

QUALIF_EXPR 

qualification 

• 

fUeLfieldl 

45 

ATrR_EXPR 

attribute 

t 

mjnteger’  image 

46 

DOTS_EXPR 

range 

•  • 

1  . .  10,  a . .  b 

47 

COMMA.EXPR 

delimiter,  separation 

a 

f(a,b,c),  a(i,j.k) 

48 

FORMAL.PARA 

formal  parameter  clause 

pi;  in,  integer 

49 

USAGE_EXPR 

defines  attributes 

@e:  red,  blue 

I 


Terminal  Nodes 


Code 

Expr  Name 

Operation 

Example 

61 

STRING_CONST 

chaicter  string 

’’abedefg” 

62 

NUMBER.CONST 

numeric  constant 

3.14 

63 

NAME 

name 

abc,  ml 

5.2  FIELDS  IN  EACH  EXPRESSION  NODE 

Of  the  7  fields  in  (he  expression  node  structure,  *nb'  and  ’nbrother*  are  not  used  for  the 
purpose  of  storing  expressions  per  se.  They  are  used  to  indicate  the  existence  of  other  related 
expressions.  Normally,  if  an  expression  has  an  ’nbrother’,  the  ’nb’  field  of  the  root  node  of  the 
expression  is  set  to  1,  and  the  ’nbrother’  field  points  to  its  ’nbrother’  expression.  Otherwise  they 
are  0  and  NULL  respectively.  Therefore,  in  the  following  description,  ’nb’  and  ’nbrother’  arc  not 
mentioned. 
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Logical  Expressions 

1.  OR_EXPR  (inclusive  disjunction) :  <exprl>  OR  <expr2> 

«xp_type  -  1  (OR_EXPR) 

no_o£_desc  ■  2 

point (1)  -  <exprl>  subtree 

point  (2)  <expr2>  subtree 

point (3)  ~  null 

no_of_char  -  0 

str_value  ■  empty  string 

2.  XOR_^EXPR  (exclusive  disjunction) :  <exprl>  XOR  <expr2> 

exp__type  -  2  (XOR_EXPR) 

no_o£_desc  ■  2 

point  (1)  <exprl>  subtree 

point (2)  -  <expr2>  subtree 

point (3)  “  null 

no_of_char  -  0 

str_value  -  empty  string 

3.  AND__EXPR  (conjunction)  :  <exprl>  AND  <expr2> 

•>tp_type  -  3  (AND_EXPR) 

no_of_desc  -  2 

point  (1)  -  <exprl>  subtree 

point  (2)  -  <expr2>  subtree 

point  (3)  *  null 

no_o£_char  ■  0 

8tr_value  -  empty  string 

4.  HOT_EXPR  (logical  negation) :  NOT  <expr> 

exp_type  -  4  (NOT_EXPR) 

no_o£_desc  -  1 

point  (1)  -  <expr>  subtree 

point (2)  -  null 

point  (3)  ■■  null 

no_of_char  -  0 

str_value  «•  empty  string 

Relational  Expressions 

I.  GT_EXPR  (greater  than) ;  <exprl>  >  <expr2> 

exp_type  -  11  (GT_EXPR) 

no_o£_desc  •  2 

point  (1)  -  <exprl>  subtree 

point  (2)  «  <expr2>  subtree 

point  (3)  -  null 

no__o£_char  -  0 

8tr_value  -  empty  string 
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2.  GE_EXPR  (greater  than  or  equal  to) :  <exprl>  >-  <expr2> 

•xp_type  -  12  (GE_EXPR) 

no_of_desc  ■  2 

point (1)  ■  <exprl>  subtree 

point  (2)  >■  <expr2>  subtree 

point  (3)  null 

no_of_char  -  0 

str_value  “  enpty  string 

3.  EQ_EXPR  (equal  to)  :  <exprl>  ■  <e3^r2> 

exp__type  -  13  (EQ_EXPR) 

no_of_desc  -  2 

point  (1)  ■■  <exprl>  subtree 

point (2)  ■  <expr2>  subtree 

point  (3)  null 

no_of_char  ■  0 

8tr_value  ■  empty  string 

4.  NE_EXPR  (not  equal  to)  :  <exprl>  /-  <expr2> 

exp_type  -  14  (NE_EXPR) 

no_o£_desc  -  2 

point  (1)  <exprl>  subtree 

point (2)  ■  <expc2>  subtree 

point (3)  •  null 

no_o£_ehar  •  0 

gtr__valu0  •  nmpty  string 

5.  LT^EXPR  (less  than) :  <exprl>  <  <expr2> 

exp_type  •  15  (LT_EXPR) 

no_o£_de8C  -  2 

point (1)  -  <exprl>  subtree 

point (2)  -  <expr2>  subtree 

point (3)  «  null 

no_of_char  -  0 

3tr_value  -  empty  string 

6.  LE_EXPR  (less  than  or  equal  to)  :  <exprl>  <•*  <expr2> 

exp_typ>e  16  (LE_EXPR) 

no_of_desc  “  2 

point  (1)  <exprl>  subtree 

point  (2)  *  <expr2>  subtree 

point (3)  *  null 

no_of_char  ■  0 

8tr_value  ••  enpty  string 
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Arithmetic  Expressions 

1.  PLUS_EXPR  (addition,  binary  operation) :  <exprl>  *  <expr2> 

®xp_type  -  21  (PLUS_BXPR) 

no_o£_de8c  ■  2 

point  (1)  *  <exprl>  aubtree 

point  (2)  -  <expr2>  subtree 

point (3)  -  null 

no_o£_char  *  0 

8tr_value  -  eiif>ty  string 

2.  PLUS_EXPR  (identity,  unary  operation)  :  +  <expr> 

exp_type  -  21  (PLUS_EXPR) 

no_o£__de8C  ■  1 

point (1)  ~  <expr>  aubtree 

point  (2)  null 

point  (3)  -  null 

no_o£_char  -  0 

str_value  ■  empty  string 

3.  MINUS__EXPR  (subtraction,  binary  operation)  :  <exprl>  -  <expr2> 

exp_type  -  22  (MINUS_EXPR) 

no_o£_deac  -  2 

point  (1)  -  <exprl>  subtree 

point  (2)  -  <expr2>  aubtree 

point  (3)  »  null 

no_o£_char  -  0 

str__value  -  eng>ty  string 

4.  MINUS_EXPR  (negation,  unary  operation) :  -  <expr> 

exp__type  -  22  (MINUS_EXPR) 

no_o£__desc  »  1 

point  (1)  -  <expr>  subtree 

point  (2)  -  null 

point (3)  -  null 

no_of_char  -  0 

8tr__value  -  eir^ty  string 

5.  TIMES_EXPR  (multiplication)  :  <exprl>  •  <expr2> 

exp_type  -  23  (TIKES_EXPR) 

no_o£_desc  -  2 

point  (1)  ••  <exprl>  subtree 

point (2)  -  <expr2>  subtree 

point  (3)  null 
m  no_o£_char  ■  0 

str_value  >■  eog>ty  string 
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6. 


DXV_EXPR  (division)  :  <exprl>  /  <expr2> 


«xp_type  -  24  (DIV_EXPR) 

no_o£_desc  ■  2 

point  (1)  ~  <exprl>  subtree 

point  (2)  -  <expr2>  subtree 

point  (3)  -  null 

no_of_char  ■  0 

str_value  ■  empty  string 


7.  EXPNT_EXPR  (exponentiation)  :  <exprl>  **  <expr2> 


exp_type  -  25  (EXPKT_EXPR) 

no_of_desc  ■  2 

point  (1)  “  <exprl>  subtree 

point  (2)  <expr2>  subtree 

point (3)  “  null 

no_of_char  ■  0 

str_value  -  empty  string 


8.  MOD_EXPR  (modulus) :  <exprl>  MOD  <expr2> 

exp_type  ■  26  (MOD_EXPR) 

no_o£_desc  -  2 

point  (1)  “  <exprl>  subtree 

point  (2)  -  <expr2>  subtree 

point  (3)  "  null 

no_of_chat  ■  0 

str__value  ••  empty  string 

9.  REM_EXPR  (remainder)  :  <exprl>  REM  <expr2> 

exp_type  -  27  (REM_EXPR) 

no_o£_de3c  ■  2 

point  (1)  <exprl>  subtree 

point  (2)  ■>  <expr2>  subtree 

point  (3)  ■  null 

no_of_char  ■  0 

8tr_value  ■  enpty  string 

10.  ABS_EXPR  (absolute  value)  :  ABS  <expr> 


exp_type  -  28  (ABS_EXPR) 

no_o£_desc  ■  1 

point  (1)  ■■  <expr>  subtree 

point  (2)  null 

point  (3)  ■  null 

no_o£_char  ■  0 

8tr_value  -  erpty  string 
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String  Concatenation 


1.  CONCAT  EXPR  (concatenation) :  <exprl>  c  <expr2> 


ejq>_type 
no_o£_desc 
point (1) 
point (2) 
point (3) 
no_of_char 
atr  value 


31  (COnCAT^EXPR) 
2 

<exprl>  subtree 
<expr2>  subtree 
null 
•  0 

empty  string 


Miscellaneous  Expressions 

1.  PAREN_EXPR  (parentheses)  :  (<expr» 

exp_type  -  41  (PAREN_EXPR) 

no_o£_desc  “  1 

point  (1)  <expr>  subtree 

point (2)  ■  null 

point (3)  ■  null 

no_of_char  ••  0 

atr_value  ■  empty  string 

2.  SUBSCR_EXPR  (subscripted  variables):  <exprl> (<expr2>) 

exp_type  -  42  (SUBSCR_EXPR) 

no_o£_desc  2 

point (1)  *  <exprl>  subtree,  the  variable 

point (2)  *  <expr2>  subtree,  the  subscripts 

point (3)  •  null 

no_,o£_char  ■  0 

str_value  •  empty  string 

3.  FUNCTION_EXPR  (function  calls)  :  <exprl>(<expr2>) 

exp_type  -  43  (FUHCTION_EXPR) 

no_of_desc  «  2 

point  (1)  ■■  <exprl>  subtree,  the  function  name 

point  (2)  <expr2>  subtree,  the  actual  parameters 

point (3)  ■  null 

no_of__chat  ■  0 

atr_value  empty  string 

4.  QUALIF_EXPR  (qualification)  :  <exprl>  .  <expr2> 

exp_type  -  44  (Q0ALIF_EXPR) 

no_of_desc  -  2 

point  (1)  ■*  <exprl>  subtree,  such  as  record  name 

point  (2)  <expr2>  subtree,  such  as  component  in  record 

point (3)  *  null 

no_of_char  “  0 

str_value  ■  ei(f>ty  string 

5.  ATTR_EXPR  (attribute)  :  <exprl>  '  <e:q>r2> 

®J*P_tyP«  -  45  (ATTR_EXPR) 

no  of  desc  «  2 
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point  (1)  <exprl>  subtree 
point  (2)  «  <expr2>  subtree 

point (3)  *  null 

no_o£_chsr  •  0 

str^value  -  eiopty  string 

6.  DOTS_EXPR  (range) :  <exprl>  . .  <expr2> 

exp_typ«  -  (DOTS_EXPR) 

no_of_desc  ■  2 

point  (1)  <exprl>  subtree 

point  (2)  -  <ejtpr2>  subtree 

point (3)  •  null 

no__o£_char  ■  0 

str_value  ■  empty  string 

7.  COMMA_EXPR  (delimiter,  separation) :  <exprl>  ,  <expr2> 

exp_type  -  47  (COMMA_EXPR) 

no_of_desc  ■  2 

point  (1)  >  <exprl>  subtree,  subscript  or  actual  parameter 

point  (2)  <expr2>  subtree,  subscripts  or  actual  parameters 

point  (3)  ■  null 

no_of_char  "  0 

str_value  ■  enpty  string 

8.  FORMAL__PARA  (formal  parameters) ;  I<exprl>]  (<expr2>]  t<expr3>J  I<expr4>J 

where  <expl>  >  formal  parameter  name 

<exp2>  -  mode,  »IN»,  »OUT',  or  'INOUT' 

<exp3>  *  parameter  type  name 

<exp4>  •  default  parameter  value,  may  or  may  not 
be  present 

exp_type  “  40  (FORMMj_PARA) 

no_of_deac  -  3  if  <exp4>  present,  2  if  not 

point (1)  -  <expr2>  subtree,  the  mode 

point  (2)  -  <expr3>  subtree,  the  typ>e  name 

point (3)  -  <expr4>  subtree,  the  default  value  if  present 

null  if  absent 

no_of_char  -  length  of  the  formal  parameter  name,  <exprl> 
str  value  *  the  formal  parameter  name 
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9.  USAGE_EXPR  (expression  usage  indication) :  6C:  <expr> 

where  C  is  a  single  character  indicating  the  usage  of  <expr>. 


oxp.type  -  49  (USAGE_EXPR) 

no_of_desc  ■  1 

point  (1)  <expr>  subtree 

point  (2)  ■>  null 

point (3)  o  null 

■  - 

no_of_char  -  length  of  the 

character 

string  in  '  str__value 

”  Str_value  *C«MMEHT* 

if 

C-'C' 

■"  "DELTA* 

if 

C-»D' 

"ENUMER* 

if 

C-'E' 

•DIGIT* 

if 

C-'G» 

•INITIAL* 

if 

C-'I' 

•LENGTH* 

if 

C-»L' 

•NEW 

if 

C-»N' 

•PACKING* 

if 

C-'P' 

•RANGE* 

if 

C-'R' 

•LAYOUT* 

If 

For  each  comment  a  usage  expression  node  (exp_iype=USAGE_EXPR) 
with  a  string  constant  node  (exp_type=STRING_CONST)  has  its  only  de- 
scendent  (pointfl)),  which  contains  the  comment  as  its  ’str.value’. 

In  general,  the  usage  expression  of  the  comment  is 

’pbrother’  (before)  or 

’nbrother  ’  (after)  of  the  neighboring  expression  node  which  has  higher  prece' 
dence. 


Terminal  Nodes 

10.  STR1NG_C0NST 

exp_type 
no_of_desc 
point (1) 
point (2) 
point (3)  < 

no_of__char 

8tr_value 

11.  NUMBERJCONST 

exp_type 
no_o£_desc 
point (1)  • 

point (2)  • 

point (3) 
no_o£_char 
str  value 


(character  strings) :  "abc  xyz* 


61  (STRINGjCONST) 

-  0 
null 
null 
null 

*  length  of  8tr_value,  not  including  quotes, 
7  in  this  example 
••  character  string  *abc  xyz* 

(numbers):  3.1416 


62  (NUMBERJCONST) 

-  0 
null 
null 
null 

■>  length  of  str^value,  6  in  this  example 
•  character  string  *3.1416” 
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12.  NAME  (nanes) :  HATRZX_3 


•xp_typ«  -  63  (NAME) 

no_of_de8C  ■  0 

point (1)  •  null 

point (2)  -  null 

point (3)  >  null 

no_of_char  •>  length  of  8tr_value,  8  ir 
8tr_value  -  character  atring  *MATRIX_3‘' 


exan^le 


5  J  TREE  CONSTRUCTION  EXAMPLES 

Example  1 

In  the  following,  an  expression,  a*bK/d,  is  used  to  illustrate  how  an  expression  subtree  is 
constructed.  A  horizontal  rectangle  represents  a  non-terminal  node;  while  a  vertical  rectangle 
represents  a  terminal  node.  Each  small  box  in  the  rectangle  represents  a  field  in  the  structure.  A 
field  from  which  an  arrow  comes  out  means  a  pointer;  otherwise,  it  is  an  integer  or  a  character 
string  with  its  value  indicated.  For  clarity  only  the  fields  involved  are  indicated. 


Ekwuntary  Statement  Lanfuages 


Memo! 


Example  2 

A  function  call,  f(a*b4c/d,X'i-y),  is  used  to  illustrate  how  such  an  expression  tree  is 
constructed. 


In  the  above  diagram.  M,  N,  L,  K  and  J  represent  expiesson  types  as  follows: 


M  »  FUNCnON_EXPR 
N  =  PROGRAM_NAME 
L  =  COMMA_EXPR 
J  =  VAR_NAME 
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A  qualified  name  a(k).b(ij+l)  can  be  stored  as  follows: 


M«m»2 


In  the  above  diagram,  X<  Y<  Z,  W,  V,  and  U  represent  expression  types  as  follows: 

X  *  QUALir_BXPR 
T  >  SUBSCR~KXPR 
S  •  VAR_NM<B 
m  m  coMMAjtxpn 
V  >  PXX78_ixPR 

O  ■  MOMBER  (XmST 
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Example  5 


RECORD_TYPE  |alpha_type)  IS  RECORD 

»x0— exp_type-NAME 
nb-0 

nbrother->null 
no__o£_deac«0 
point (i)«null 
no__o£_cha  r«l  0 
8tt_value“ 

•alpha__typ«* 


1601; 


exp__type“‘USAGE_EXPP 

nb"0 

nbrother-null 
no__of_desc“l 
point  (1)“ 
point (2) “nullN. 
point (2) -null  \ 
no__o£_char“6  ' 
atr  value*" LENGTH* 


exp_type-NUMBER_CONST 

nb-0 

nbrotheronull 
no_o£_de8C«0 
point (i)*null 
no_o£__char-3 
atr  value-'lSO" 


Example  6 

VARIABLE  (third) 


((INTEGER)  (OR:0..255)  (eP:0*NORD)  (OYiO..*?)); 
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•xp__typ«“HAMB 

nb«0 

nbroth«r*null 
no_of__desc«0 
point (i)-null 
no__o£_char-5 
8tr  value“*thitd" 


exp_type“HAME 

nb-1 

nbrother-  •— 
no_of^desc-0 

point  (i)<^ull 
no_o£_char“7 
str_value« 
"INTEGER* 


exp_type* 

USAGE_EXPR 

■  nb*l 

nbrot  he  r»  e  — ■  ■ 
no__o£_de8c- 
point 

point  (2)  “null 
point  (3)‘-nui\ 
no_^o£_char-5  i 
str_value*  I 
"RANGE"  / 


exp_type- 

USAGBJEXP 

nb*l 

nbrother*  •— 
no__of_de8C“l 
point  |1>“% 
point  (2)«n^l 
point  (3)^uil 
no_of_cha  r-j 
8tt_value*  / 
"PACKING" 


exp_type- 

USA6E_EXPR 

nb*0 

■  nbrother~null 
no_of__desc*l 
point  (D-  • 
point (2) -null 
point (3) *nuil 
no_of_char-tf 
8tr_value- j 
"LAYOUT 


exp_type'“ 

NUMBER^COHST 

nb-0 

nb  r  ot  he  r-nu  1 1 
no_o£_de8C-0 
point  (i)*null 
no_o£_char>«l 
str  value* 


exp_type“ 

DOTS_EXPR 

nb“0 

nbrother*null 
no_o£_de8c-2 
point  (1)* 
point (2)*  • 
point  (3)-nu\l 
no_o£__char*d 
8tt  value-  JL'"' 


«*p_typ«" 

NUfBERjCONST 

nb-0 

nbrothec— nul 
no__o£_de8c-0 
point (i)-nuy 
no_o£_cha  r-1 
8tt  value-  I 


*p_type- 
NUMBER_CONST 
nb-0 

nbrother-null 
no_o£jdeac-0 
point (i)-null 
no_o£_char-l 
8tr  value- 


exp_type- 

DOTS_EXPR 

nb-0 

nbrother-null 
no_o£_desc-2 
point (1)- 
point (2)-  e 
point (3) -null 
no_,e£_char-d 
str  value- 


8tr_value- 

NUMBER_CONST 

nb-0 

nbrother-null 
no__o£_de8c-0 
point (i) -null 
no_o£_char-l 
str  value- 


•*p_typ«- 

NOKBERjCONST 

nb-0 

nbrother-null 
no_o£_de  sc-0 
point (i)-null 
no_o£__char-l 
8tr_value- 
"0"~ 


exp_type- 

NAME 

nb-0 

nbrother-null 

no_o£_de8C-0 

point (i)-null 

no_o£_char-4 

8tr_value- 

•NORD" 
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Example  7 


VARZABXJS  (tran)  (alpha^type)  ^911:0.. 4); 


•xO' 


exp__typ«* 

”name 

nb*0 

nbrother»null 
no__of__de3c«'0 
point  (1)  ■•null 
no__of_char'-4 
8tt_VBlue“ 
"tran" 


exl 


exp_type*» 

NAME 

nb«0 

nbrother>null 
no__o£_de8C«0 
point (i) *null 
no__o£_char-l0 
8tt_valu«« 

•alpha^^^typa' 


•x3 


•xp_type- 

NUMBERjCONS^ 

nb**0 

nbrother*null 
no_o£^d8sc«0 
point (i) •null 
no__o£ jcha  r*  1 
8tr  valoa"*©" 
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Memo  2 


Example  8 

Tt«  comm,  operator  is  used  for  dcUmiUng  the  Usts  of  subscripts  such  as  those  in  A(ij) 
in  functions  such  as  ADDf^b^).  Urn  are  stor«i  as  follows 
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Appendix:  ESL  Statement  Code 


A.I.  Declaration  Statements 


■ 

STATEMENT 

STATEMENT 

STATEMENT 

■ 

TYPE 

SUB  TYPE 

TYPE  NAME 

CODE 

1. 

Program  Type  Block 

task 

TASK^TYPE 

1 

- 

generic 

GENERIC 

2 

2. 

Structure  type  Block 

record  type 

RECORD.TYPE 

11 

3. 

Variable  Type  Terminal 

variable  type 

VARIABLE_TYPE 

21 

4. 

Program  Unit  Block 

system 

SYSTEM 

31 

program  file 

PROGRAM.FILE 

32 

package 

PACK.SPEC 

33 

task 

TASK.SPEC 

34 

procedure 

PROC.SPEC 

35 

function 

FCN_SPEC 

36 

program  body 

PACK_BODY 

37 

TASK.BODY 

38 

PROC.BODY 

39 

FCN.BODY 

40 

begin-end 

BEGIN 

41 

exception 

EXCEPTION.DCL 

42 

EXCEPTION.HNDLR 

43 

select 

SELECT 

44 

5. 

Structure  Block 

record 

RECORD 

51 

6. 

Variable  Terminal 

variable 

VARIABLE 

61 

constant 

CONSTANT 

62 

a 

File  Terminal 

i/o  nie 

lO.FILE 

71 

■ 

i/o  device 

lO.DEVICE 

um 

1 

task  entry 

TASK^ENTRY 

9! 

8. 

Comment  Tenninal 

ordinary 

ORD.COMMENT 

81 

preprocess 

PREP.COMMENT 

82 

compiler 

COMP.COMMENT 

83 

debugging 

DEBUG.COMMENT 

84 
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A.2.  Executable  Statements 


STATEMENT  TYPE 

STATEMENT  SUBTYPE 

STMT.TYPE  NAME 

1. 

Condition 

if-then-elsc 

IF.STAT 

101 

Block 

case 

CASE^STAT 

when 

WHEN^STAT 

n 

2. 

Loop 

while 

WHILE^STAT 

IBM 

Block 

until 

UNTIL.STAT 

m 

for 

FOR.STAT 

m 

3. 

Assignment 

Terminal 

assignment 

ASSIGN.STAT 

121 

il 

Procedure  Call 

call 

CALL_STAT 

BB 

■ 

Terminal 

raise  exception 

RAISE_STAT 

Ri 

5. 

Message 

send/receive  message 

MSG.CALL 

141 

Terminal 

accept  message 

MSG.ACCEPT 

142 

6. 

Input/Output 

read 

READ.STAT 

SI 

■ 

Terminal 

write 

WRITE.STAT 

|g 

B 

I/O  Auxiliary 

open 

OPEN_FILE 

mg 

1 

Terminal 

close 

CLOSE^FILE 

m 

■ 

position 

POSITION.FE.E 

mM 

8. 

Context 

with 

WITH.STAT 

nn 

Terminal 

use 

USE_STAT 

program.separate 

PACK  SEP 

Km 

TASK  SEP 

174 

PROC_SEP 

175 

FCN.SEP 

176 

separate 

SEPARATE_STAT 

177 

9. 

Cbntrol  Transfer 

return 

RETURN  STAT 

181 

Terminal 

go-to  * 

GOTO 

182 

exit* 

EXIT 

183 

null* 

NULL 

184 

*  Extension  eliminated  in  later  translation. 
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